[Seaside] Re: [Seaside-commits] aubergines/seaside Seaside2.mc,1.14,1.15

[Julian Fitzell]

Nevin Pratt wrote:
> 
> 
> Julian Fitzell wrote:
>> I'm not sure how it helps with loggin though.  #start and #start: are 
>> only called once at the beginning of a session. 
> 
> 
> 
> Custom WASession subclasses could use it.

It's still only going to get called once for each user session.

>>
>>
>> Presumably for logging we'd want to add some more info the the 
>> WARequest object and then you could write a Filter to be applied to 
>> every seaside request.  Though... doesn't Comanche do logging of some 
>> kind?  What do you want to log that you can't do at that level? 
> 
> 
> 
> Comanche won't log Seaside component accesses.  It can only log URL's. 
> And Seaside's URL's aren't particularly meaningful in a log.

Ok, didn't realize the level of logging you were talking about.

> If a subclass of WAKom can figure out what Seaside component(s) is/are 
> being accessed when it sees a given Seaside URL, then I think Comanche 
> logging can do it all.  Otherwise, Seaside must do the logging.

No, WAKom definitely cannot figure that out.  But then, nothing really 
know every component that's getting used... what exactly are you wanting 
to log?  Trace messages through the whole render chain?  With the URLs 
logged at least you can pull up the URL and see the complete state :)

> And if Seaside is doing the logging, there is a bunch of stuff in the 
> Comanche HttpRequest that it needs.
> 
> And off hand, I don't see a way for the WAKom subclass to know the 
> components (and subcomponents) that are being accessed via a given URL. 
> Seaside is just too dynamic for that.  After all, it's not hard to have 
> a given component hot swap another component on the fly.  Just set an 
> instance variable in the Seaside component to contain a subcomponent 
> that it wants rendered for that access.  How in the world could Comanche 
> possibly know it did that?
> 
> Thus, I lean towards giving Seaside more HttpRequest knowledge.

Not arguing about giving it more knowledge of the HTTP request (we've 
always intended to do that, just haven't had a need yet) it's just 
HttpRequest that we don't want to push into Seaside.  That's *why* 
WARequest is there.  And like I said, if we need to add more parameters 
to it, we can just do so.  But by having WARequest we can use any server 
we want behind the scenes and it just populates the WARequest: 
completely transparent to Seaside.  That's why we have WAKom: to do that 
translation.

Julian