You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Jesse Kuhnert <jk...@gmail.com> on 2006/02/01 19:09:28 UTC
Tapestry 4.1 AJAX support (& other things)
There have been a lot of perfectly valid concerns/questions/etc regarding
where/how tapestry plans to provide ajax integration. Just yesterday I
answered a private email to someone else outlining in very very slim terms
what I hoped to do, but since we're all doing it now I suppose I can't
procrastinate with a wiki page promise any longer..
Firstly I would like to say that it is my very sincere hope that nothing
going on here would be a suggestion that tapestry should be embracing any
one component library over the other. Tacos has a great number of faults, as
do other libraries I've seen. Not all are completely perfect, but a healthy
community of varying implementations is what keeps us all honest :)
All of that being said, I hope everyone knows that what I want to do in
tapestry is much more ambitious than what is seen in the current
implementation of tacos today :) My only hope is to expose/fix/adjust
whatever portions of the framework made doing things in tacos hard, so that
doing all of these things is a lot easier. I'd ultimately like to make some
additional component contributions/adjustments , but am not overly concerned
with getting them into the core as it is just as easy to do it in projects
like tacos ;)
There are also some semi political sounding sort of processes I'd like to
startup in the hopes that the community can become a little bit more
involved and self managing. Like a component promotion/incubation program.
If tapestry goes to a top level project then it would be very easy to create
a sort of component inspection committee where people like
Robert/Ron/Leonardo/etc. could hold votes and make decisions about whether
they think a particular component should be promoted/etc.. Don't know yet
what the process would be to hand it off to someone in the higher level
framework area but it sounds good in theory..
I will start with the core changes and work my out to more specific things
like components.
-) Rendering Contributions - Though it is not documented anywhere, and as
far as I can tell has never been used by anyone tacos did(does) start the
notion of varying ajax client/server implementations, which is one of the
reasons why I was able to quickly switch gears and abandon prototype as the
tacos core client library and switch to dojo.
This service is more or less an extension plugin-in sort of hivemind
contribution point. Involved in the mechanics are the core
AjaxDirectService, RenderDelegateFactory and the actual ResponseBuilder
implementations. It is the job of the RenderDelegate to look at the incoming
http headers and whatever else it can, while working with the response
builder contributions to determine what kind of request has been receieved,
as well as who would like to handle it. This currently covers prototype and
dojo. It used to also cover rico, but that project is dead and now the core
developer is working for yahoo.
What all of these configuration/contribution points provide is the ability
to "plug in" to all the hard work that makes some of what tacos does
possible. Things like partial rendering of responses, dynamic script
contribution manipulations, form component semantics, new cycle definitions
for the client side state (ie before/during/after render on client browser)
, etc...
Most of the architecture of this system is still much less than ideal. I
don't want components having to know that they are involved in anything ajax
related, much less actually call any specific apis to do anything about it..
I have absolutely no idea what (if any) crossover there would be for this
same concept in tapestry. It is my hope that with enough gentle refactoring,
well defined extension points, there won'tbe as much of a need to do these
taco -ish sort of things anymore.
-) Component Ids / Form Component Ids - Howard seems to be addressing these
already with some new ideas. It's an incredibly hard problem to solve and I
don't envy him for it, but it's also one huge stumbling block for anything
client js related. I could go on and on in this section, but I think
everyone knows what we are talking about.
-) Rewind cycle adjustments - I think howard is also working on this, but
the basic gist of what I'd like to do would be to have the ability to
"partially" validate/parse form submissions so that a finer grained
interaction with the client page is also possible.
-) New state management concepts - Though there certainly is a lot of work
to do on the server end of the spectrum in regard to state, there are also a
number evolving design patterns related to all of these dynamic client
interactions. Some of them would be better supported by a clear model for
knowing what the client-side state is on the server and vice versa. (Ie
widgets, visibility of, etc..) See
http://codinginparadise.org/weblog/2006/01/ajaxdhtml-tutorial-should-i-render-my.html.
-) New script contribution nodes - The current @Script contributions are
extremely powerful and flexible. I would like to add a couple additional
nodes to the existing body/unique/initialization steps. These would mostly
serve to make the pre/during/post "client render cycle" a lot easier to
handle than defining obscure custom protocols within each library.
-) Hivemind Service COMM Api - Though it is very nice and easy to interact
with tapestry to do partial page rendering, it really doesn't always make
sense depending on what you are doing on the client. Sometimes you really
just need to hit a method on a service and return some data, nothing
specific to an actual html block.
I have a number of libraries I've not shared with tacos or anyone else that
have started this design interaction. Basically, it's sort of equivalent to
things like DWR, only a little more in line with simpler design and of
course my undying love of the dojo library ;)
There are also some other more interesting debates/research efforts underway
to define more clearly what exactly the best interactions are depending on
the context in which you need to communicate. (ie,
http://blogs.ebusiness-apps.com/dave/?p=68 )
This area should provide a much richer support layer for people that prefer
thick client -> thin server interactions.
- ) New components ! - Yes of course I want to either enhance or provide new
components. This is sort of the very last step though. I think 90% of the
work will go into providing the plumbing to make a ~lot~ of new technologies
easier to use with tapestry, but not force any one particular implementation
on people.
- ) Javascript core interactions - While I haven't really worked this part
out yet to be honest, I ~would~ like to use dojo to do some of the basic
tapestry javascript interactions. Originally I had thought this would apply
only to very specific "ajax" component implementations, but the more code I
saw/user issues I read about the more and more I started thinking that
tapestrys javascript portions needed some refactoring as well.
Things like event handling, client side validation, window load / unload
semantics (ok, so that's event handling again ;) ) are all things that I
think tapestry would benefit from greatly if using a more robust client-side
library than our own custom implementations.
The other important thing to think about here is that things really have/are
changing in our deployment client of choice, the web browser. While we were
all happily coding away at this and that in the java world (not all of us,
howard has always provided direct Scripting support from what I can tell,
don't know how he manages to keep doing things right all the time, we'll
catch him slipping at some point ;) ) the browser folks quietly sort of
fixed a lot of the major problems encountered in the browser.
Javascript is a real language. It isn't java, but it's not intended to be.
It's our client technologies most powerful form of interaction and shouldn't
be taken lightly. While we can continue to roll our own solutions in regard
to this, I've found it incredibly cumbersome and time consuming to do so. I
think using a library of some sort makes a lot of sense. It hides all of the
cross browser scripting issues we run into, provides unified ways of
interacting with the DOM/events/etc.. You could just as easily say that java
doesn't make sense as a GUI platform as well.
I'm all for providing as much flexibility and openness as possible, just
tell me how to do it. Unless someone is able to provide a layer of
abstraction on top of the client library of choice (ie commons-logging,
~swing~, awt, etc..) then I don't know how we're going to do it.
None of this means that dojo needs to necessarily be forced on anyone for
their uses of ajax-specific interactions, but at the very least I'd like to
use it for basic plumbing jobs in tapestry. Like event handling and form
validation.
Tapestry folks should also be aware of the amount of upcoming support being
provided in this area as well. Like eclipse's upcoming support via IBM (
http://news.zdnet.com/2100-9593_22-6033544.html) , as well as being the
growing foundation for a number of other well known entities:
- Yahoo (now moving to the core, not just flickr)
- AOL (ie http://blog.dojotoolkit.org/2006/01/30/dojo-iamalpha-and-cdns )
- Webwork
- Django
- RoR (i know some dev's doing it, don't know if it's openly talked about
there or not)
- IBM
- some .Net libraries, don't remember who/ where
- Eclipse
- etc ettc...
There are a lot of others but I can't keep track of them all. It seems like
every other day that we here new announcements on the dev list of this or
that framework providing direct integrated support for it.
So where does everyone see us heading?
Re: Tapestry 4.1 AJAX support (& other things)
Posted by Norbert Sándor <de...@erinors.com>.
I think that it would be better to have an external js library included with
tapestry. Your validation example was very good: why have a custom one in
the tapestry core if DOJO has a good and continously developed one?
Maybe this would free some tapestry developer resources as well.
DOJO seems to be a very good choice nowdays, it not only has some AJAX
components but a very good base infrastructure!
Based on the DOJO dev list a big amount of development is going on to
dissolve the performace and "unnecessary including of packages" problems in
DOJO.
So including DOJO does not mean that it will be loaded in each page. But
components should have a choice during rendering to include the required
DOJO packages. And a smarter Shell component would take care of the
optimizations (maybe not including any DOJO files at all if not needed).
About AJAX. As I see most web frameworks will (or do) support it out of the
box, so tapestry should do it, too. For example it's not good to have two
separate Form or DirectLink components (1 for normal and 1 for ajax). This
means that some (minimal?) integration of AJAX to the core is necessary.
Regards,
Norbi
----- Original Message -----
From: "Jesse Kuhnert" <jk...@gmail.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Thursday, February 02, 2006 5:49 AM
Subject: Re: Tapestry 4.1 AJAX support (& other things)
Ok, sounds good...
On a side note, I'm not dead set against not including dojo in tapestrys
core, I just want to be sure it's for a very good reason as it will sort of
take some of the fun out of what I'm doing. It's not a ~must have~. The ajax
support will still work either way..
On 2/1/06, Ron Piterman <rp...@gmx.net> wrote:
>
> as mentioned in my previous postings, its quite a time difference, so I
> will set some test tommorow...
> Cheers,
> Ron
>
> Jesse Kuhnert wrote:
> > There is a delay whenever using a dojo page - I see it more at home than
> >
> >
> >>on my dev box, and that concerns me:
> >>I don't know what dojo does that makes the browser think twice before it
> >>shows a page but it does somthing, and this 0.5 seconds (in the good
> >>case) where my browser window is white - this 0.5 seconds will lead my
> >>customers to click to the competitor's web site, so I just can not
> >>afford it.
> >>
> >>this "white delay" exists also to some extent in prototype but dojo
> >>breaks the records there...
> >>As said, in (current) tapestry pages (also with forms) this does not
> >>happen, and as for me, it also shouldn't.
> >
> >
> >
> > I'd be very interested in knowing if you experienced this delay if you
> > configured dojo using "parseWdigets: false" in your djConfig variable.
> > That's the exact reason why you experienced delays a long time ago, and
> was
> > addressed in my previous email I believe.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.25/247 - Release Date: 2006. 01.
31.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 4.1 AJAX support (& other things)
Posted by Jesse Kuhnert <jk...@gmail.com>.
Ok, sounds good...
On a side note, I'm not dead set against not including dojo in tapestrys
core, I just want to be sure it's for a very good reason as it will sort of
take some of the fun out of what I'm doing. It's not a ~must have~. The ajax
support will still work either way..
On 2/1/06, Ron Piterman <rp...@gmx.net> wrote:
>
> as mentioned in my previous postings, its quite a time difference, so I
> will set some test tommorow...
> Cheers,
> Ron
>
> Jesse Kuhnert wrote:
> > There is a delay whenever using a dojo page - I see it more at home than
> >
> >
> >>on my dev box, and that concerns me:
> >>I don't know what dojo does that makes the browser think twice before it
> >>shows a page but it does somthing, and this 0.5 seconds (in the good
> >>case) where my browser window is white - this 0.5 seconds will lead my
> >>customers to click to the competitor's web site, so I just can not
> >>afford it.
> >>
> >>this "white delay" exists also to some extent in prototype but dojo
> >>breaks the records there...
> >>As said, in (current) tapestry pages (also with forms) this does not
> >>happen, and as for me, it also shouldn't.
> >
> >
> >
> > I'd be very interested in knowing if you experienced this delay if you
> > configured dojo using "parseWdigets: false" in your djConfig variable.
> > That's the exact reason why you experienced delays a long time ago, and
> was
> > addressed in my previous email I believe.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
Re: Tapestry 4.1 AJAX support (& other things)
Posted by Ron Piterman <rp...@gmx.net>.
as mentioned in my previous postings, its quite a time difference, so I
will set some test tommorow...
Cheers,
Ron
Jesse Kuhnert wrote:
> There is a delay whenever using a dojo page - I see it more at home than
>
>
>>on my dev box, and that concerns me:
>>I don't know what dojo does that makes the browser think twice before it
>>shows a page but it does somthing, and this 0.5 seconds (in the good
>>case) where my browser window is white - this 0.5 seconds will lead my
>>customers to click to the competitor's web site, so I just can not
>>afford it.
>>
>>this "white delay" exists also to some extent in prototype but dojo
>>breaks the records there...
>>As said, in (current) tapestry pages (also with forms) this does not
>>happen, and as for me, it also shouldn't.
>
>
>
> I'd be very interested in knowing if you experienced this delay if you
> configured dojo using "parseWdigets: false" in your djConfig variable.
> That's the exact reason why you experienced delays a long time ago, and was
> addressed in my previous email I believe.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 4.1 AJAX support (& other things)
Posted by Jesse Kuhnert <jk...@gmail.com>.
There is a delay whenever using a dojo page - I see it more at home than
> on my dev box, and that concerns me:
> I don't know what dojo does that makes the browser think twice before it
> shows a page but it does somthing, and this 0.5 seconds (in the good
> case) where my browser window is white - this 0.5 seconds will lead my
> customers to click to the competitor's web site, so I just can not
> afford it.
>
> this "white delay" exists also to some extent in prototype but dojo
> breaks the records there...
> As said, in (current) tapestry pages (also with forms) this does not
> happen, and as for me, it also shouldn't.
I'd be very interested in knowing if you experienced this delay if you
configured dojo using "parseWdigets: false" in your djConfig variable.
That's the exact reason why you experienced delays a long time ago, and was
addressed in my previous email I believe.
Re: Tapestry 4.1 AJAX support (& other things)
Posted by Ron Piterman <rp...@gmx.net>.
Jesse Kuhnert wrote:
> That seems like a very valid concern. (good morning to you as well...or good
> night? ;) )
>
> I'm not quite sure how to best answer that question to be honest. I have to
> be honest that I am trying to enlist the help of other more qualified
> sources for a better answer. We'll see what they say.
>
> The very basics of form interactions are still a concern of my own. I do see
> the point of not liking the idea of having dojo, however small and
> compressed the core dl may be, being forced on you in certain areas whether
> you like it or not. What then prevents your problem from having
> Form.jsforced on you when using the Form component? Small and concise
> it may be,
> but I would argue that
> http://archive.dojotoolkit.org/nightly/src/validate.js is equally as small
> and focused, only better.
There is a delay whenever using a dojo page - I see it more at home than
on my dev box, and that concerns me:
I don't know what dojo does that makes the browser think twice before it
shows a page but it does somthing, and this 0.5 seconds (in the good
case) where my browser window is white - this 0.5 seconds will lead my
customers to click to the competitor's web site, so I just can not
afford it.
this "white delay" exists also to some extent in prototype but dojo
breaks the records there...
As said, in (current) tapestry pages (also with forms) this does not
happen, and as for me, it also shouldn't.
>
> Of course if you don't have client validation enabled then there wouldn't be
> any automatic validate.js inclusions on your page. Just as much as
> http://archive.dojotoolkit.org/nightly/src/rpc/JsonService.js wouldn't be
> included on your page unless you were using JSON specific features.
>
> I do have to admit though that I'm rather enamored with the concept of being
> able to do this on one of my pages without very much thought:
>
> <script type="text/javascript" >
> dojo.require("dojo.validate");
>
> do Some weird validation...
>
> or...
> dojo.require("dojo.storage.Storage");
>
> and then being able to play with the stored flash state that tapestry has in
> my form with very well defined and easy to use API's.
> </script>
>
>
> I don't know. Is this a question of which library should be included by
> default, or are you saying that you think the tapestry dev's should continue
> to manually write their own javascript libraries so that tapestry isn't
> percieved as being particularly fond of one implementation over another?
>
> Javascrip gets loaded into the browser by tapestry already whether people
> like it or not, it's more a question of ~which~ javascript we want getting
> loaded into our browsers..A highly evolved/dynamic/supported/tested library
> maintained by very focused developers, or a mishmash of varying javascript
> styles being maintained by an already overburdened tapestry development
> team?
Thats certainly not my point, since in case of dojo it seems one is on
the safe side - ideology does not play a role here...
>
> I think more likely than not that the core of your argument is the download
> size of the core dojo.js library file, whichever custom profile you have
> decided to build?
>
> This is the only point I can't dismiss without further help/support. You are
> able to build as large or small a dojo.js file as you like, depending on how
> much you want to be available in your sharable/cachable js package. Whatever
> you don't want to include in the core will still be available via more
> "cachable" javascript inclusion calls.
>
> If this is related to your experiences with tacos, then I should probably
> apologize ahead of time. There was a huge design oversight that I hadn't
> realized I had committed until only a week or two ago...Which is that if you
> don't configure it to be off by default dojo will attempt to parse the DOM
> of your page for each page load to see if you have defined any dojo
> "widgets" that need parsing/configuring.
>
> I was planning on having this feature off by default for any/everything
> tapestry related. We already have a well defined model for dealing with
> components. (Just set djConfig { parseWidgets: false } . )
>
> Would this be resolvable if I were able to put up a web page somewhere with
> a very simple interface that just downloads dojo.js with widget parsing
> turned off, say, providing focus to a sample form input field?
I just looked at tacos demo again - don't know its current state but it
is not very fast loading, to say the least.
I will be glad to look at whatever you want to show me...
Cheers,
Ron
>
> j
> On 2/1/06, Ron Piterman <rp...@gmx.net> wrote:
>
>>My concern is very simple, I take my current project as example:
>>
>>There are portions where Ajax is so important I will infact restrict
>>those portions to browsers supported by the ajax implementation we will
>>use.
>>
>>Then again, there are portions of the application - say, login page,
>>where all I want is deliver good functionality to all users on all
>>browsers and *fast*, without having to give away very basic things that
>>are presently there like the nice focus feature of the form component.
>>
>>Now do I need dojo for that very basic functionality? - and I am not
>>talking even about the Date component - just the very basics.
>>
>>What is the cost of using dojo? for me right now it seems simply too
>>heavy on the browser -
>>
>>I don't think we are in a position to make tapestry the bleading edge
>>framework for web 2.0 only - and say, well, out applications do have
>>some (performance) problems when you surf them on a PII win98 machine.
>>
>>now about tacos->tapestry, I think we see it alike.
>>for me, I am convinced that the existance of tacos (and some other
>>libraries which *will* come soon ;-) ) is an oxygen for the evolvement
>>of tapestry - decentralisation, letting the community evolve and live
>>its own life and make that interact etc.
>>
>>Cheers and again, good morning...
>>Ron
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 4.1 AJAX support (& other things)
Posted by Jesse Kuhnert <jk...@gmail.com>.
That seems like a very valid concern. (good morning to you as well...or good
night? ;) )
I'm not quite sure how to best answer that question to be honest. I have to
be honest that I am trying to enlist the help of other more qualified
sources for a better answer. We'll see what they say.
The very basics of form interactions are still a concern of my own. I do see
the point of not liking the idea of having dojo, however small and
compressed the core dl may be, being forced on you in certain areas whether
you like it or not. What then prevents your problem from having
Form.jsforced on you when using the Form component? Small and concise
it may be,
but I would argue that
http://archive.dojotoolkit.org/nightly/src/validate.js is equally as small
and focused, only better.
Of course if you don't have client validation enabled then there wouldn't be
any automatic validate.js inclusions on your page. Just as much as
http://archive.dojotoolkit.org/nightly/src/rpc/JsonService.js wouldn't be
included on your page unless you were using JSON specific features.
I do have to admit though that I'm rather enamored with the concept of being
able to do this on one of my pages without very much thought:
<script type="text/javascript" >
dojo.require("dojo.validate");
do Some weird validation...
or...
dojo.require("dojo.storage.Storage");
and then being able to play with the stored flash state that tapestry has in
my form with very well defined and easy to use API's.
</script>
I don't know. Is this a question of which library should be included by
default, or are you saying that you think the tapestry dev's should continue
to manually write their own javascript libraries so that tapestry isn't
percieved as being particularly fond of one implementation over another?
Javascrip gets loaded into the browser by tapestry already whether people
like it or not, it's more a question of ~which~ javascript we want getting
loaded into our browsers..A highly evolved/dynamic/supported/tested library
maintained by very focused developers, or a mishmash of varying javascript
styles being maintained by an already overburdened tapestry development
team?
I think more likely than not that the core of your argument is the download
size of the core dojo.js library file, whichever custom profile you have
decided to build?
This is the only point I can't dismiss without further help/support. You are
able to build as large or small a dojo.js file as you like, depending on how
much you want to be available in your sharable/cachable js package. Whatever
you don't want to include in the core will still be available via more
"cachable" javascript inclusion calls.
If this is related to your experiences with tacos, then I should probably
apologize ahead of time. There was a huge design oversight that I hadn't
realized I had committed until only a week or two ago...Which is that if you
don't configure it to be off by default dojo will attempt to parse the DOM
of your page for each page load to see if you have defined any dojo
"widgets" that need parsing/configuring.
I was planning on having this feature off by default for any/everything
tapestry related. We already have a well defined model for dealing with
components. (Just set djConfig { parseWidgets: false } . )
Would this be resolvable if I were able to put up a web page somewhere with
a very simple interface that just downloads dojo.js with widget parsing
turned off, say, providing focus to a sample form input field?
j
On 2/1/06, Ron Piterman <rp...@gmx.net> wrote:
>
> My concern is very simple, I take my current project as example:
>
> There are portions where Ajax is so important I will infact restrict
> those portions to browsers supported by the ajax implementation we will
> use.
>
> Then again, there are portions of the application - say, login page,
> where all I want is deliver good functionality to all users on all
> browsers and *fast*, without having to give away very basic things that
> are presently there like the nice focus feature of the form component.
>
> Now do I need dojo for that very basic functionality? - and I am not
> talking even about the Date component - just the very basics.
>
> What is the cost of using dojo? for me right now it seems simply too
> heavy on the browser -
>
> I don't think we are in a position to make tapestry the bleading edge
> framework for web 2.0 only - and say, well, out applications do have
> some (performance) problems when you surf them on a PII win98 machine.
>
> now about tacos->tapestry, I think we see it alike.
> for me, I am convinced that the existance of tacos (and some other
> libraries which *will* come soon ;-) ) is an oxygen for the evolvement
> of tapestry - decentralisation, letting the community evolve and live
> its own life and make that interact etc.
>
> Cheers and again, good morning...
> Ron
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
Re: Tapestry 4.1 AJAX support (& other things)
Posted by Ron Piterman <rp...@gmx.net>.
My concern is very simple, I take my current project as example:
There are portions where Ajax is so important I will infact restrict
those portions to browsers supported by the ajax implementation we will use.
Then again, there are portions of the application - say, login page,
where all I want is deliver good functionality to all users on all
browsers and *fast*, without having to give away very basic things that
are presently there like the nice focus feature of the form component.
Now do I need dojo for that very basic functionality? - and I am not
talking even about the Date component - just the very basics.
What is the cost of using dojo? for me right now it seems simply too
heavy on the browser -
I don't think we are in a position to make tapestry the bleading edge
framework for web 2.0 only - and say, well, out applications do have
some (performance) problems when you surf them on a PII win98 machine.
now about tacos->tapestry, I think we see it alike.
for me, I am convinced that the existance of tacos (and some other
libraries which *will* come soon ;-) ) is an oxygen for the evolvement
of tapestry - decentralisation, letting the community evolve and live
its own life and make that interact etc.
Cheers and again, good morning...
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 4.1 AJAX support (& other things)
Posted by Ron Piterman <rp...@gmx.net>.
Hi jesse,
Now dojo is a universe of its own - I could try and findle my way in,
but would be greatfull if you have a working example that shows how
sleek some basic functionalities might be using dojo for the present
core functionality of tapestry forms...
All the examples I have seen until today did prove the contrary...
Cheers,
Ron
Jesse Kuhnert wrote:
> There have been a lot of perfectly valid concerns/questions/etc regarding
> where/how tapestry plans to provide ajax integration. Just yesterday I
> answered a private email to someone else outlining in very very slim terms
> what I hoped to do, but since we're all doing it now I suppose I can't
> procrastinate with a wiki page promise any longer..
>
> Firstly I would like to say that it is my very sincere hope that nothing
> going on here would be a suggestion that tapestry should be embracing any
> one component library over the other. Tacos has a great number of faults, as
> do other libraries I've seen. Not all are completely perfect, but a healthy
> community of varying implementations is what keeps us all honest :)
>
> All of that being said, I hope everyone knows that what I want to do in
> tapestry is much more ambitious than what is seen in the current
> implementation of tacos today :) My only hope is to expose/fix/adjust
> whatever portions of the framework made doing things in tacos hard, so that
> doing all of these things is a lot easier. I'd ultimately like to make some
> additional component contributions/adjustments , but am not overly concerned
> with getting them into the core as it is just as easy to do it in projects
> like tacos ;)
>
> There are also some semi political sounding sort of processes I'd like to
> startup in the hopes that the community can become a little bit more
> involved and self managing. Like a component promotion/incubation program.
> If tapestry goes to a top level project then it would be very easy to create
> a sort of component inspection committee where people like
> Robert/Ron/Leonardo/etc. could hold votes and make decisions about whether
> they think a particular component should be promoted/etc.. Don't know yet
> what the process would be to hand it off to someone in the higher level
> framework area but it sounds good in theory..
>
> I will start with the core changes and work my out to more specific things
> like components.
>
> -) Rendering Contributions - Though it is not documented anywhere, and as
> far as I can tell has never been used by anyone tacos did(does) start the
> notion of varying ajax client/server implementations, which is one of the
> reasons why I was able to quickly switch gears and abandon prototype as the
> tacos core client library and switch to dojo.
>
> This service is more or less an extension plugin-in sort of hivemind
> contribution point. Involved in the mechanics are the core
> AjaxDirectService, RenderDelegateFactory and the actual ResponseBuilder
> implementations. It is the job of the RenderDelegate to look at the incoming
> http headers and whatever else it can, while working with the response
> builder contributions to determine what kind of request has been receieved,
> as well as who would like to handle it. This currently covers prototype and
> dojo. It used to also cover rico, but that project is dead and now the core
> developer is working for yahoo.
>
> What all of these configuration/contribution points provide is the ability
> to "plug in" to all the hard work that makes some of what tacos does
> possible. Things like partial rendering of responses, dynamic script
> contribution manipulations, form component semantics, new cycle definitions
> for the client side state (ie before/during/after render on client browser)
> , etc...
>
> Most of the architecture of this system is still much less than ideal. I
> don't want components having to know that they are involved in anything ajax
> related, much less actually call any specific apis to do anything about it..
>
> I have absolutely no idea what (if any) crossover there would be for this
> same concept in tapestry. It is my hope that with enough gentle refactoring,
> well defined extension points, there won'tbe as much of a need to do these
> taco -ish sort of things anymore.
>
> -) Component Ids / Form Component Ids - Howard seems to be addressing these
> already with some new ideas. It's an incredibly hard problem to solve and I
> don't envy him for it, but it's also one huge stumbling block for anything
> client js related. I could go on and on in this section, but I think
> everyone knows what we are talking about.
>
> -) Rewind cycle adjustments - I think howard is also working on this, but
> the basic gist of what I'd like to do would be to have the ability to
> "partially" validate/parse form submissions so that a finer grained
> interaction with the client page is also possible.
>
> -) New state management concepts - Though there certainly is a lot of work
> to do on the server end of the spectrum in regard to state, there are also a
> number evolving design patterns related to all of these dynamic client
> interactions. Some of them would be better supported by a clear model for
> knowing what the client-side state is on the server and vice versa. (Ie
> widgets, visibility of, etc..) See
> http://codinginparadise.org/weblog/2006/01/ajaxdhtml-tutorial-should-i-render-my.html.
> -) New script contribution nodes - The current @Script contributions are
> extremely powerful and flexible. I would like to add a couple additional
> nodes to the existing body/unique/initialization steps. These would mostly
> serve to make the pre/during/post "client render cycle" a lot easier to
> handle than defining obscure custom protocols within each library.
>
> -) Hivemind Service COMM Api - Though it is very nice and easy to interact
> with tapestry to do partial page rendering, it really doesn't always make
> sense depending on what you are doing on the client. Sometimes you really
> just need to hit a method on a service and return some data, nothing
> specific to an actual html block.
>
> I have a number of libraries I've not shared with tacos or anyone else that
> have started this design interaction. Basically, it's sort of equivalent to
> things like DWR, only a little more in line with simpler design and of
> course my undying love of the dojo library ;)
>
> There are also some other more interesting debates/research efforts underway
> to define more clearly what exactly the best interactions are depending on
> the context in which you need to communicate. (ie,
> http://blogs.ebusiness-apps.com/dave/?p=68 )
>
> This area should provide a much richer support layer for people that prefer
> thick client -> thin server interactions.
>
> - ) New components ! - Yes of course I want to either enhance or provide new
> components. This is sort of the very last step though. I think 90% of the
> work will go into providing the plumbing to make a ~lot~ of new technologies
> easier to use with tapestry, but not force any one particular implementation
> on people.
>
> - ) Javascript core interactions - While I haven't really worked this part
> out yet to be honest, I ~would~ like to use dojo to do some of the basic
> tapestry javascript interactions. Originally I had thought this would apply
> only to very specific "ajax" component implementations, but the more code I
> saw/user issues I read about the more and more I started thinking that
> tapestrys javascript portions needed some refactoring as well.
>
> Things like event handling, client side validation, window load / unload
> semantics (ok, so that's event handling again ;) ) are all things that I
> think tapestry would benefit from greatly if using a more robust client-side
> library than our own custom implementations.
>
>
> The other important thing to think about here is that things really have/are
> changing in our deployment client of choice, the web browser. While we were
> all happily coding away at this and that in the java world (not all of us,
> howard has always provided direct Scripting support from what I can tell,
> don't know how he manages to keep doing things right all the time, we'll
> catch him slipping at some point ;) ) the browser folks quietly sort of
> fixed a lot of the major problems encountered in the browser.
>
> Javascript is a real language. It isn't java, but it's not intended to be.
> It's our client technologies most powerful form of interaction and shouldn't
> be taken lightly. While we can continue to roll our own solutions in regard
> to this, I've found it incredibly cumbersome and time consuming to do so. I
> think using a library of some sort makes a lot of sense. It hides all of the
> cross browser scripting issues we run into, provides unified ways of
> interacting with the DOM/events/etc.. You could just as easily say that java
> doesn't make sense as a GUI platform as well.
>
> I'm all for providing as much flexibility and openness as possible, just
> tell me how to do it. Unless someone is able to provide a layer of
> abstraction on top of the client library of choice (ie commons-logging,
> ~swing~, awt, etc..) then I don't know how we're going to do it.
>
> None of this means that dojo needs to necessarily be forced on anyone for
> their uses of ajax-specific interactions, but at the very least I'd like to
> use it for basic plumbing jobs in tapestry. Like event handling and form
> validation.
>
> Tapestry folks should also be aware of the amount of upcoming support being
> provided in this area as well. Like eclipse's upcoming support via IBM (
> http://news.zdnet.com/2100-9593_22-6033544.html) , as well as being the
> growing foundation for a number of other well known entities:
>
> - Yahoo (now moving to the core, not just flickr)
> - AOL (ie http://blog.dojotoolkit.org/2006/01/30/dojo-iamalpha-and-cdns )
> - Webwork
> - Django
> - RoR (i know some dev's doing it, don't know if it's openly talked about
> there or not)
> - IBM
> - some .Net libraries, don't remember who/ where
> - Eclipse
> - etc ettc...
>
> There are a lot of others but I can't keep track of them all. It seems like
> every other day that we here new announcements on the dev list of this or
> that framework providing direct integrated support for it.
>
> So where does everyone see us heading?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org