On Fri, 2003-11-21 at 21:38, Timothy Larson wrote: > --- Bruno Dumon <[EMAIL PROTECTED]> wrote: > > On Fri, 2003-11-21 at 21:01, Timothy Larson wrote: > > > So far, I lean toward using an *optional* set of explicit views. > > > > But with explicit views, you would still need to know what view was used > > when a form is submitted, so the name of the view would then be embedded > > in the form itself? > > True, but it is less hidden data to pass back and forth across the network > or to store in the continuation. By the way, what if this data (either the > view name or the list of widgets sent) could be stored in a hidden field > or in the continuation?
Sure, might be possible, but I don't want this to be the only way since I don't want woody to depend on continuations. But it would be easy enough to do both, i.e. first check if the continuation has this information, else check for a hidden request parameter, or else assume all widgets were in the template. > The decision could be made per form based on how > much secure enforcement is needed (store in continuation) versus how much > we offload from the server to the client (store in a hidden field). > > > A problem I see with explicit views is that they need to be static > > (IIUC). I think a common use case will be that the template file is > > processed by the JXTemplate generator and that some widgets will be > > included conditionally. > > In some cases the view could be dynamically "static" using static > expression of dynamic union semantics. "some cases", yes, but not all. > In this case the stored > data (either in the continuation or a hidden field) would be the > view name plus some parameters. Seems like a lot of trouble to save some bytes... We could also zip the list of id's to make it smaller. But anyway, if it can be stored in the continuation, and since that is what most people will be using anyway, then that seems like a good solution. > > > > This may even lead to the possibility of the view introducing > > > view-specific widgets, driven by the same general set of needs > > > that produced the aggregate widget. > > > > Could you expand a bit on this? > > Not a concrete thought, just a feeling. I will let you know if the > idea gells into anything useful enough that I could express it. ok > The aggregate field and its inverse (which is not created yet) hold > a concept that could live in the form definition or in a view or > template. The way I see it handling request parameters is exactly the purpose of a widget, but I'm curious to what you can come up with. > Currently it just happens to only live in the definition. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
