It's good to see that active development is going on!
I missed that javadoc thing, would you point me to that message?
Although I think I would not like using javadoc for such purpose...
BR,
Norbi
Jesse Kuhnert wrote:
P.S. In an effort to not add even more interfaces(or xml configurations)
that we'll need to break out of in tapestry 5 I was pondering using qdox
javadoc annotations to mark some of these new methods as Howard had
mentioned before, along with the real native annotations of course.
Any thoughts on this one ? They seem to work out fairly well for testng, and
since it's one portion of knowledge I'm a little more familiar with after
working with it I feel less scared to try and introduce it.
It does start to introduce a new component writing style though, which may
end up doing more harm than good.
On 4/18/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
As noted by Brian earlier the unit tests are all running happily again
which means that my initial phase of mucking with the render cycle is
finished. (Initial as in there's something there that will probably work but
is probably not completely done changing yet).
I'd love any feedback people have on it. The parts that I'm not at all
happy with are the tricky little sections in AbstractComponent /
AbstractPage / Shell / (maybe one or two other of our core components )
where I had to delegate some method calls off to the new "ResponseBuilder"
interface. The solution I have in place isn't ideal by any means, but it may
mostly work for now. I think either some AOP love or breaking interface
changes are the only other options I can think of to give it a better
implementation. I'm going to skip the AOP part for now as I'm guessing it
will require a large mental investment for me to learn it on a level that is
needed to introduce it to tapestry.
The next phase will ~finally~ be interacting with the client side again. I
have the PropertySelection component working properly with JSON requests via
the dojo ComboBox widget already as a proof of concept(it currently only
switches to client side queries when the component parameter
'filterOnChange' is set to true), mostly as a starting proof of concept.
I'm going to probably just hit one thing at a time now (hopefully faster
than what it took to break all of the tapestry internals and slowly
re-fix/factor them again after introducing the ResponseBuilder) , starting
with the <initializtion> element in the @Script component which should
probably connect to window onload events or similar depending on the context
of the response..Ie for normal responses load with window.onload event /
for ajax almost immediately / etc...
I'm thinking that this will work in a similar fashion to the
ResponseBuilder, a configurable set of script manager sort of API's will be
consulted to determine how these core interactions should be imlpemented
client side scripting wise. (Ie for dojo we'll wrap the entire block with
dojo.event.connect(window, "onload") , if someone feels like imlpementing
the prototype api they can use Event.Observe() instead. )
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://opennotion.com
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://opennotion.com
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.3/316 - Release Date: 2006.04.17.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
