I propose the following to move on: As I mentioned earlier, I have been planning a review of the view API after I get done with some basic documentation. Due to the discussion I will now change my plans and create an overview and proposal for the view API today. Now that a few people have tried out the tools we can have a discussion on this. I had a look at the message tool by Nathan. I don't think it is so fundamentally that we woundn't find a common ground. So far we havn't really thought much about the design of the view API. The focus has be more on proofing the concept that Velocity and Struts without major changes on either side.
Look for a mail later today. Gabe "Geir Magnusson Jr." wrote: > > On 2/12/02 10:49 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote: > > > "Geir Magnusson Jr." wrote: > >> Inserting into the request is problematic, as this makes some assumptions. > > > > The new support for modular applications relies on a request-scope > > object, so this will be the cannonical Struts approach. > > What happens if someone wants to use the struts controller outside of the > servlet API? > > > > > > >> What I think would be nice is if there was a map of the data elements in the > >> servlet scopes, so anyone could write a tool to access what they needed. > >> You also then don't have to have agreement on what this tool is called, what > >> the interfaces look like, etc. > > > > That's part of what the ContextHelper can do. Someone could just tap > > into the accessors for the data elements, to get what they needed for > > their own presentation layer. > > Ah - so nothing *except* the ContextHelper will be in the scopes? > > > The end-game would be to turn around and have the tag exensions use this > > object too. So, it's going to be there whether someone chooses to use it > > or not. > > Yep. Although maybe you could start the game that way :) > > > > >> In Velocity, since we don't have any trouble accessing things that aren't > >> simple property getter/setter methods, we can access a really rich API, and > >> therefore would be pleased to avoid a lowest-common-denominator object > >> provided by the controller. > > > > I actually like to think of it as a highest-common-denominator object > > =:o) > > As long as the API isn't shaped by the necessity of being dumbed-down to a > bean for easy tag access, indeed... > > -- > Geir Magnusson Jr. [EMAIL PROTECTED] > System and Software Consulting > The bytecodes are language independent. - Sam Ruby > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Gabriel Sidler Software Engineer, Eivycom GmbH, Zurich, Switzerland -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
