First impressions

> Hi Edward,
>
> First let me welcome to the Aida world. And we appreciate any fresh
> impressions views on Aida, because those views help improving it most,
> so please continue with them.
>
> Answers to your questions are below.
>
>
> Edward Stow wrote:
>
> > preferedURL
> > -----------------
> > My application requires RESTful urls and bookmarkable urls.  The
> > caching of object / url references caused me some delay while working
> > on my own application.
> >
> > Suggestion:  Add a documentation note to the tutorial on how to reset
> > the cache. (If you had user comments section on your documentation,
> > this note would have been added by now.)
> >
> > Is it necessary to cache the references at all.  Is this a performance
> > issue or part of the basic design?
> > Could this be a configuration option for a production system.
>
> By "caching" you probably mean an URLResolver and his memory of
> Url-object mappings. If you want to remove some object from here, use
>
> AIDASite default urlReslover removeObject: myObject.
>
> If you like to change Url to a new prefered one, just do
>
> AIDASite default urlReslover changeToPreferedURL: myObject
>
> Or did I miss your point?
>
>
> > WebApplication  >> observee
> > -----------------------------------------
> >  --- I know that names are only names but it was not until I realized
> > that your observee is what many other mvc frameworks would call the
> > model.  In my mind model objects are designed to be observed.  I would
> > have found a comment to this effect helpful in the documentation.
>
> Agree, that point more to clarify better in documentation. Tutorial was
> not clear enough on that?
>
> > Error reporting on the web page.
> > ---------------------------------------------
> > Make an error that causes a dnu -- the page should display some
> > diagnostics on the error.  The debugger stack would be useful at
> > least.  Seaside really excels in this area - being able to jump to the
> > debugger, fix and proceed.
>
> This is done better in VW but on Squeak I don't yet understand exception
> management well. In VW you got an UHE window while on browser you got
> 500 internal server error. And UHE stays there until you come around and
> look at it, usually with a whole stack preserved. Tha't really very
> handy for maintenance of production servers, where you usually come
> around later and not exactly at the time of user having an error. I
> propose that we did the same on Squeak too

> whila adding a debugging in a
> web browser I don't find very usefull from end user standpoint. Maybe
> from developer, but again, this is more "cool" that useful IMO.
>
> > So far I'm enjoying the experience ...
>
> Nice to hear that!
>
> JAnko
>
>