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]
