Oh, so you are already doing what was described to me then (I left the
event/command parts out to avoid any gui comparison pooh poohs but you're
already way ahead of that..).

Sounds good.

Another question coming into my head is, at what point do we get to treat
js/flash like we would switching jre versions? It seems like it's been a
really loooooooooooong time since we've all been making concessions for
non-flash or non-javascript client browsers..

On 1/31/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
>
> My vision for state changing components like For is to introduce an
> extra layer of control.
>
> Instead of the For component just updating its instance variable, it
> should record, with some page-global objects, a Command for making the
> change.
>
> The Command will be executed during the render.
>
> The interface for Command will probably be
>
> void execute(IComponent component); the control layer will store and
> serialize a ComponentAddress; during the subsequent request, it will
> use the ComponentAddress to reaquire the component and pass it to the
> Command. The Command impl will downcast and invoke.
>
> In addition, the Commands will be collected and serialized.  The
> direct service will encode these serialized commands as a new query
> parameter, pagestate.
>
> By deserializing and executing these Commands, the page state can be
> restored to the render state as it was during the render process, just
> before triggering the component and its listener.
>
> There are a couple of minor issues ... for instance, a For component
> will render a series of contradictory state (that is, item1, item2,
> item3 ...) do we need to store, in the pagestate query parameter, all
> of those in sequence, or just the most recent one?
>
> This is a solution I hope to implement for 4.1 and certainly for 5.
>
> On 1/31/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
> > comments inlined
> >
> > I'm prototyping some stuff right now that I'd have to call Tapestry 5.
> > > I don't think there's a way to remove inheritance in the Tapestry 4
> > > code base without distorting many interfaces and breaking backwards
> > > compatibility.
> >
> > Sounds like a great idea. Everything from 4.0 -> 5 should hopefully
> provide
> > you with enough breathing room to do it. It should also allow you to
> break
> > whatever you want. I think it's high time..
> >
> >
> > > - Vastly simplified API
> > > - Clear deliniation between public/stable and
> private/internal/unstable
> > > APIs
> > >
> > > Sounds awesome. The only other tiny eclispe-extension-ish thing I
> wanted
> > to throw in was the example that I had been given which sounded
> reasonable
> > to me. ...It's almost the same IRender delegate idea that's already
> being
> > used, however formally.
> >
> > The For loop currently does a reasonable amount of work in it's main
> > renderComponent method, which is perfectly acceptable design-wise, all
> > methods are about as focused and concise as they can be. The only
> problem
> > is, esp in my case, there are many many times when you want to change
> the
> > behaviour of something like this during the loop...So, some sort of
> built-in
> > mechanism to provide extensibility ahead of time might be something to
> > ponder. Would look sort of like:
> >
> > For:: protected void renderComponent(writer, cycle) {
> >
> >      int counter = 0;
> >      loop(onsomething; counter++) {
> >
> >          if (loopDelegate != null)
> >             loop.delegateBeforeIteration(writer,cycle, counter,
> > currentValue);
> >             renderBody(writer,cycle);
> >
> >         if (loopDelegate != null)
> >              loop.delegateAfterIteration(writer, cycle,
> > counter,currentValue);
> >
> >      }
> > }
> >
> >
> > The example is probably naive, but just the idea of something like that
> > sounds very powerful...
> >
> > j
> >
> >
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work.  http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to