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
