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

[Nevin Pratt]

Julian Fitzell wrote:

> Nevin Pratt wrote:
>
>>
>>
>> jfitzell at users.sourceforge.net wrote:
>>
>>> Modified Files:
>>>     Seaside2.mc Log Message:
>>> Add #start: to WASession.  This method gets called instead of #start 
>>> when a new session is begun.  It is passed the request so you can 
>>> look for GET parameters or whatnot.  Then it calls #start.
>>>
>>>  
>>>
>>
>> It is passed the Comanche session?
>>
>> If so, that is great, as it finally allows reasonable session logging 
>> code to now be grafted in.
>>
> (I'm gonna copy the list on this, hope you don't mind)
>
> No, it's passed the WARequest.  We don't want to pass Comanche objects 
> straight in because that forces the use of Comanche.  But anything we 
> want to populate WAResponse with from the comanche session, we could do.
>
> 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.

>
>
> 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.

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.

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.

Nevin