About observee

Hello!

After finishing the tutorial (mostly
copy&paste) I went trough the code again and
come up with two questions:

a) What does observee actualy do?
in `self observee addresses do: [:each |`
observee does what?

b) How to start with blank sheet?
Tutorial adds new page to a site. How does one
start with empty site and builds from there?

Kind regards,
Damir Horvat

On Wed, 30 May 2007 00:38:08 +0200
Damir Horvat <damir at x-si.org> wrote:

> Hello!
>
> After finishing the tutorial (mostly
> copy&paste) I went trough the code again and
> come up with two questions:
>
> a) What does observee actualy do?
> in `self observee addresses do: [:each |`
> observee does what?

You'll have multiple instances of any given view in your system, once
the app is running and in use. Every single view has to know which
domain object is being displayed in it. observee is this reference.

>
> b) How to start with blank sheet?
> Tutorial adds new page to a site. How does one
> start with empty site and builds from there?

That depends on what you mean with "empty site".
Are you referring to the navigation links here?

Regards,
s.

On Wed, May 30, 2007 at 03:04:16PM +0200, Stefan Schmiedl wrote:

> You'll have multiple instances of any given view in your system, once
> the app is running and in use. Every single view has to know which
> domain object is being displayed in it. observee is this reference.

I get it. Whenever I'd like to display object's value in a view,
I need 'observee' to get the reference to that object.

> >
> > b) How to start with blank sheet?
> > Tutorial adds new page to a site. How does one
> > start with empty site and builds from there?
>
> That depends on what you mean with "empty site".
> Are you referring to the navigation links here?

In tutorial, I only added new page (addressbook.html) to existing
site with top and left (menu) section already added.

I'd like to start with new site, and entering www.site.tld would
display index.html view.


Thanks for your help.

Damir Horvat

Stefan Schmiedl wrote:
> On Wed, 30 May 2007 00:38:08 +0200
> Damir Horvat <damir na x-si.org> wrote:
  a) What does observee actualy do?
>> in `self observee addresses do: [:each |`
>> observee does what?
>
> You'll have multiple instances of any given view in your system, once
> the app is running and in use. Every single view has to know which
> domain object is being displayed in it. observee is this reference.

To continue a bit: as Stefan already explained, observee is a model
object which this App is "observing" to produce its web presentation.
That way a classical MVC style of separation of domain from presentation
is achieved. This is also called an observer pattern - observer (an App)
is observing an object, while this object don't knows that it is
observed. Observee object is therefore decoupled from its observer and
this simply programming of UI apps a lot.

Best regards
Janko


--
Janko Miv?ek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Damir Horvat wrote:
If I understand you correctly, you want to open a completely new web
site, on its own hostname like www.company.com ? If so, look into
Administrator's guide, 3. Adding a new site:

        http://www.aidaweb.si/administrators-guide.html

Best regards
Janko


--
Janko Miv?ek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

On Wed, 30 May 2007 20:17:23 +0200
Janko Miv?ek <janko.mivsek at eranova.si> wrote:

>
> To continue a bit: as Stefan already explained, observee is a model
> object which this App is "observing" to produce its web presentation.
> That way a classical MVC style of separation of domain from
> presentation is achieved.

That's one thing I meant to ask you, Janko. Where's the "C" in AIDA?
I see the Model as domain objects, the viewXXX methods in the xxxApp
classes act as View, but where's the Controller supposed to be?

s.

Stefan Schmiedl wrote:
Stefan, C as Controller in MVC coresponds to actions in Aida. So, for V
you have view methods (#viewMain etc) and for C you have action methods
(#actionMain, #actionMainAdd etc). Action methods are called when you
press buttons on a web page ...

Best regards
Janko

--
Janko Miv?ek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Janko Miv?ek wrote:
I forgot to add that both view and action methods are in the same App
class. That's one of the reasons why those class names end with "App"
and not "View".


--
Janko Miv?ek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

On Wed, 30 May 2007 20:57:59 +0200
Janko Miv?ek <janko.mivsek at eranova.si> wrote:

ahh... yes. That part did not make it into long-term memory .-)

s.

Hello Damir,

I have just worked through the same process as you and here is my
understanding of some of the key methods for the site layout:

WebStyle >> pageFrameWith: wide: title: this method provides the
framework of the page, within which you can place your application (by
using 'viewMain'. You will see that it invokes 'headerBanner' and
'headerElement' for instance as well as the 'navigationBarElement'. You
can replace these various messages with your own to populate your page.

If you look at: WebStyle >> headerElement you will see that it calls
WebElement >> newId: #logo. Now look at WebStyle >> css3Header for
example, and you will see how #logo is defined in css format.

You may have worked through this already, but if not, I hope this helps,

regards
Nicholas



Damir Horvat wrote:
--

*Nicholas J Moore*
+44 7786 063 333
+33 555 092 140
+33 682 904 357
*TSR International
*Thought Leaders in Communication & Complexity
www.TSR-i.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.aidaweb.si/pipermail/aida/attachments/20070602/81fc57fd/attachment.htm 

Maybe is a time to explain a WebStyle ans styling, probably most hard to
understand feature of Aida. But very useful one.

Why feature? Because it allows to change styling (CSS) of your  website
without changing web apps. This also allows another very important
feature in web hosting environments: you can have many web sites running
in your image but each with different CSS style.

That way a separation of content from style is achieved in full. Content
is duty if your App classes while style is duty of your WebStyle classes.



Nicholas Moore wrote:
--
Janko Miv?ek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

On Sat, Jun 02, 2007 at 12:11:52PM +0200, Nicholas Moore wrote:

Actualy, I didn't. Didn't have time. But thanks for your explanation.

A soon as I get the site in condition I'd like, I'll write a post (or a
blog) about how I did it. So far, I like it a lot. Especialy the 'no
sql' part. ;-)


Br,
Damir

On Sat, 2 Jun 2007 15:30:25 +0200
Damir Horvat <damir at x-si.org> wrote:

>
> A soon as I get the site in condition I'd like, I'll write a post (or
> a blog) about how I did it. So far, I like it a lot. Especialy the 'no
> sql' part. ;-)

Which "no sql" part are you referring to?

s.

On Sat, Jun 02, 2007 at 03:38:42PM +0200, Stefan Schmiedl wrote:

> On Sat, 2 Jun 2007 15:30:25 +0200
> Damir Horvat <damir na x-si.org> wrote:
>
> >
> > A soon as I get the site in condition I'd like, I'll write a post (or
> > a blog) about how I did it. So far, I like it a lot. Especialy the 'no
> > sql' part. ;-)
>
> Which "no sql" part are you referring to?

Exactly! :-)

I'm comming from perl/ruby land and when someone mention web application,
the first questions are usualy about how to fit data into SQL.

Here, one is just to keep one root object and everything else is
referenced from there. No SQL part (at least for small apps).

Ironically, at this very moment, I was doing just that - thinking how to
put data into SQL for some web app I'm working on (using RubyOnRails).

In theory, I can see, how much easier would be to use Aida/WEB for this
project. But I have no time to loose and don't realy know Aida so well
to try it on this project.

Damir

On Sat, 2 Jun 2007 16:19:40 +0200
Damir Horvat <damir at x-si.org> wrote:

Oh, *that* part :-)

>
> I'm comming from perl/ruby land and when someone mention web
> application, the first questions are usualy about how to fit data
> into SQL.

Maybe that's because
- they have to interface to existing SQL data storage
- that's how they were brought up (the LAMP generation)

>
> Here, one is just to keep one root object and everything else is
> referenced from there. No SQL part (at least for small apps).

The last two IOWA webapps I wrote came without a database ... which
made the clients wonder how this works :-)

As a safety measure, I dump the application data periodically (2 min).

My domain objects are implemented to use one hash for instance variable
storage, which makes migrating between versions a walk in the park.
Even if I have more complex migrations to do, I just grab the dump file
from the production server, work things out on my development machine,
and when it works, I kill the server process, run the migration script
on the production server, restart the server, downtime < 10 sec,
usually unnoticed by clients.

Of course, if my ruby-fu were greater, or if I had a Smalltalk image I
could connect to, things would even be better, but as far as it goes,
it is much better than dealing with the duplication that one usually
inherits from database usage.

If you develop a new application and plan to use a database, think hard
on why you want to use it. Too much data to keep it in memory? That's a
valid reason. Client wants to access the data for further processing?
Well, generating CSV files is usually just a quick hack away, so that
does not count.

I'm curious what I will do the next time I really have to use a
database ... which will be sometime during this weekend :-)

s.

Hi Stefan,

Stefan Schmiedl wrote:
>>>> Especialy the 'no sql' part. ;-)
>>> Which "no sql" part are you referring to?
>
> Oh, *that* part :-)
>
> I'm curious what I will do the next time I really have to use a
> database ... which will be sometime during this weekend :-)

Have you already considered a Smalltalk image as a database?

Smalltalk image contains live objects too besides to compiled code. And
those live objects can be your app data. You can snapshot (save) an
image from time to time to save your "database".

I'm actually using this technique for all my recent web apps. On my
collocated server there is 20+ sites running in a single image, which
has currently 368MB and is snapshotted every hour. This takes about 3-5s
which hardly anyone notice.

Question arise: is such database safe? What if your image crash in the
middle of a hour between snapshots?

This could be a problem is image would crash frequently. But from
experience so far a VW  is very stable and above mentioned image is
running for months without stop and it never crashed so far. Even if it
will, we loose only one hour of data, which is acceptable for all but
very specific apps.

So, I recommend you to reconsider your image as a sole database and
you'll be suprised and ask yourself why you didn't come to that idea
before :)

Best regards
JAnko


--
Janko Miv?ek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

On Tue, 05 Jun 2007 11:40:42 +0200
Janko Miv?ek <janko.mivsek at eranova.si> wrote:

> Have you already considered a Smalltalk image as a database?

Yes. That would be sooo good ...

>
> Smalltalk image contains live objects too besides to compiled code.
> And those live objects can be your app data. You can snapshot (save)
> an image from time to time to save your "database".

That's what I'm doing right now with my ruby webapps, with one caveat,
described next.

> Question arise: is such database safe? What if your image crash in
> the middle of a hour between snapshots?

More important: How can I get to the data in case of
- system failures
- VM crashes
- updates

I was caught unaware once, when Dolphin 5 refused to load an object
serialized with Dolphin 4. So nowadays I wear suspenders in addition to
a belt and *also* serialize my application data in a neutral form, in
case of the ruby apps it's YAML. About once an hour or so. And mail the
backups to a remote machine. Yes I'm paranoid about my clients' data :-)

>
> This could be a problem is image would crash frequently. But from
> experience so far a VW  is very stable and above mentioned image is
> running for months without stop and it never crashed so far. Even if
> it will, we loose only one hour of data, which is acceptable for all
> but very specific apps.

This touches upon an area that I have no experience with, but need to
deal with sooner than later: Changing a remotely running application in
VW. One of the charming properties of IOWA is that you can change the
page related files and they will be reloaded (more or less) immediately.
If I'm living in an image-centric world, I guess I'll have to find a
way to periodically check for updated packages and file them in. I
wonder how often I will manage to break things there .-)

>
> So, I recommend you to reconsider your image as a sole database and
> you'll be suprised and ask yourself why you didn't come to that idea
> before :)

I would, if I could, but I cannot, you know. The current project gets
the bulk of the working data from a MSSQLServer database and, sadly,
needs to save it's "own" data back into this thing. I'm currently
undecided if it makes sense to try and fit Glorp to the messy database
schema or if I'm having a better outlook with reinventing some smaller
wheels.

BTW: AIDA behaves quite well, only I'm making *stupid* errors ... like
adding an element to self instead of the collecting WebElement.

s.