You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Sam Gendler <sg...@ideasculptor.com> on 2006/04/05 16:56:36 UTC
handling async xml requests in Tapestry - a proposal
Ive been unable to sleep, of late, worrying about my ability to
deliver a cutting edge, ajax enabled application from within Tapestry.
I chose Tapestry as a framework before I had significant user
experience, but after being utterly dissatisfied with the maturity of
all other java component-based frameworks. However, the rewind cycle
thing started to make me nervous as soon as I began to understand it,
as a good ajax application really needs to be able to make requests
back to the server that are independant of the content or structure of
a page.
I really like Tapestry's templates, which alow me to retain the
general structure of the raw html so I can work with designers easily,
and the support for internationalization is excellent, but the page
orientation of all client-server communication was making me nervous.
I believe, from some of the reading I've done, that the Tacos
components that make async requests actually cause a full rewind on
every request. More importantly, I couldn't imagine how I would
support doing things like adding new form elements from javascript.
I think I came up with a solution last night, but I can't be the only
person thinking about this problem, so I thought I'd run it past folks
here before writing it up in full and starting work on it. AT the
very least, hopefully someone will clue me in on the correct way to
handle this if my solution has holes in it that I am unaware of. So
please, bring on the constructive criticism. Also, bear in mind that
I don't have a very deep understanding of Tapestry internals yet, and
my first task will be to delve under the hood and figure out how I
would actually proceed, so I may make the occasional factual error
below.
There are a number of available tools for marshalling/unmarshalling
java objects to and from xml (or JSON or anything else. I'm fairly
agnostic on this one). The only issue is how to submit requests to the
server and get back results without having to be concerned with page
structure or doing lots of unnecessary work.
The thought I had was to add a second servlet to my webapp, one which
functions in a tapestry-esque manner (injecting services and
properties, autopopulating properties based on request contents, use
Tapestry annotations, etc), but which is 'stateless.' The Service (as
opposed to a Page) would have properties populated according to some
known scheme (in previous projects, I've used jakarta BeanUtils
notation, ognl, Maps, and other tricks, and then a listener method
would be called. The listener would either return an object which
could be marshalled back as XML/JSON/text, or would write directly to
the client. Of course, it would be easy to provide custom marshalling
mechanisms for any given class that might be returned. All that would
be required would be javascript in the page which knows how to parse
the incoming data.
Now, it is entirely possible that something like this could be built
within the confines of a Tapestry Page, perhaps by providing a new
Service, so my concept of a second servlet stems mostly from ignorance
of what is available to me, currently.
Regardless of the implementation details, the resulting app would be
quite compelling, for me, and I suspect for others. We would get
Tapestry's excellent templates/internationalization/infrastructure but
all data i/o would occur via Services instead of Pages. When Page
changes are required, and for simple forms, Tapestry Pages would still
be very useful, but much of the business logic could migrate away from
the Page rendering logic. Obviously, you'd have to be careful of the
rewind cycle when dynamically adding new input fields to a page which
might get submitted, but even that can be handled by submitting the
new objects asynchronously and then re-requesting the page
asynchronously, getting the browser version and the tapestry state
back in sync.
At any rate, in a full ajax app, it is unlikely that form data would
ever be submitted back via a regular post, so it is probably a moot
point for many, if not most 'Web 2.0' apps. There, I actually used the
term. Ugh.
These are just brief ramblings, as I have to run out, and I wanted to
get my thoughts out there before I am away froma computer for most of
the day.
So please, feel free to take my idea apart, as I am sure I'll learn
plenty in the process. In the end, so long as I can do ajax-y things
within Tapestry, I don't care how I get there.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: handling async xml requests in Tapestry - a proposal
Posted by Sam Gendler <sg...@ideasculptor.com>.
On 4/5/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> I should say something further as the last email may have sounded a little
> grumpy.
>
No offense taken. Your response was exactly what I was looking for.
I just hadn't found your wiki docs myself. I'd been all over the
Tacos site, but not into the source code yet, but documentation is a
bit sparse, so my efforts hadn't revealed much.
--sam
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: handling async xml requests in Tapestry - a proposal
Posted by Jesse Kuhnert <jk...@gmail.com>.
I should say something further as the last email may have sounded a little
grumpy.
I definitely welcome any/all discussions / help with this stuff. No matter
what form it may be in. The only thing I ask is that everyone does their
homework first before coming to the table for discussions.
On 4/5/06, Jesse Kuhnert <jk...@gmail.com> wrote:
>
> http://wiki.apache.org/jakarta-tapestry/Tapestry41Roadmap
>
> I would take a look at the ajax sections outlined towards the bottom. This
> work is already currently underway.
>
>
> On 4/5/06, Sam Gendler <sg...@ideasculptor.com> wrote:
> >
> > Ive been unable to sleep, of late, worrying about my ability to
> > deliver a cutting edge, ajax enabled application from within Tapestry.
> > I chose Tapestry as a framework before I had significant user
> > experience, but after being utterly dissatisfied with the maturity of
> > all other java component-based frameworks. However, the rewind cycle
> > thing started to make me nervous as soon as I began to understand it,
> > as a good ajax application really needs to be able to make requests
> > back to the server that are independant of the content or structure of
> > a page.
> >
> > I really like Tapestry's templates, which alow me to retain the
> > general structure of the raw html so I can work with designers easily,
> > and the support for internationalization is excellent, but the page
> > orientation of all client-server communication was making me nervous.
> > I believe, from some of the reading I've done, that the Tacos
> > components that make async requests actually cause a full rewind on
> > every request. More importantly, I couldn't imagine how I would
> > support doing things like adding new form elements from javascript.
> >
> > I think I came up with a solution last night, but I can't be the only
> > person thinking about this problem, so I thought I'd run it past folks
> > here before writing it up in full and starting work on it. AT the
> > very least, hopefully someone will clue me in on the correct way to
> > handle this if my solution has holes in it that I am unaware of. So
> > please, bring on the constructive criticism. Also, bear in mind that
> > I don't have a very deep understanding of Tapestry internals yet, and
> > my first task will be to delve under the hood and figure out how I
> > would actually proceed, so I may make the occasional factual error
> > below.
> >
> >
> >
> > There are a number of available tools for marshalling/unmarshalling
> > java objects to and from xml (or JSON or anything else. I'm fairly
> > agnostic on this one). The only issue is how to submit requests to the
> > server and get back results without having to be concerned with page
> > structure or doing lots of unnecessary work.
> >
> > The thought I had was to add a second servlet to my webapp, one which
> > functions in a tapestry-esque manner (injecting services and
> > properties, autopopulating properties based on request contents, use
> > Tapestry annotations, etc), but which is 'stateless.' The Service (as
> > opposed to a Page) would have properties populated according to some
> > known scheme (in previous projects, I've used jakarta BeanUtils
> > notation, ognl, Maps, and other tricks, and then a listener method
> > would be called. The listener would either return an object which
> > could be marshalled back as XML/JSON/text, or would write directly to
> > the client. Of course, it would be easy to provide custom marshalling
> > mechanisms for any given class that might be returned. All that would
> > be required would be javascript in the page which knows how to parse
> > the incoming data.
> >
> > Now, it is entirely possible that something like this could be built
> > within the confines of a Tapestry Page, perhaps by providing a new
> > Service, so my concept of a second servlet stems mostly from ignorance
> > of what is available to me, currently.
> >
> > Regardless of the implementation details, the resulting app would be
> > quite compelling, for me, and I suspect for others. We would get
> > Tapestry's excellent templates/internationalization/infrastructure but
> > all data i/o would occur via Services instead of Pages. When Page
> > changes are required, and for simple forms, Tapestry Pages would still
> > be very useful, but much of the business logic could migrate away from
> > the Page rendering logic. Obviously, you'd have to be careful of the
> > rewind cycle when dynamically adding new input fields to a page which
> > might get submitted, but even that can be handled by submitting the
> > new objects asynchronously and then re-requesting the page
> > asynchronously, getting the browser version and the tapestry state
> > back in sync.
> >
> > At any rate, in a full ajax app, it is unlikely that form data would
> > ever be submitted back via a regular post, so it is probably a moot
> > point for many, if not most 'Web 2.0' apps. There, I actually used the
> > term. Ugh.
> >
> > These are just brief ramblings, as I have to run out, and I wanted to
> > get my thoughts out there before I am away froma computer for most of
> > the day.
> >
> > So please, feel free to take my idea apart, as I am sure I'll learn
> > plenty in the process. In the end, so long as I can do ajax-y things
> > within Tapestry, I don't care how I get there.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> 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
Re: handling async xml requests in Tapestry - a proposal
Posted by Sam Gendler <sg...@ideasculptor.com>.
> I don't know what problems you had with tacos, as I find it very useful for
> thin client style tapestry apps, but of course this won't work quite as well
> for your thick needs.
>
My only problem with tacos, so far, has been that the Palette control,
whether contrib or tacos version, doesn't work if you have a
DirtyFormWarning on the form. Not only does the warning not detect
changes to the Palette, but the Palette always submits an empty list.
I wasn't referring to problems. I was referring to how much work you
had to do to get Tacos functional in Tapestry. I want to get to a
point where I can build components much more easily than it was for
you.
--sam
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: handling async xml requests in Tapestry - a proposal
Posted by Jesse Kuhnert <jk...@gmail.com>.
Yeah I don't think a month is going to produce a complete ajax api for
anyone that I'd want to base business decisions on.
I'm pretty dedicated to tapestry, as I get paid to work on it/ dojo full
time now I have a vested interest in seeing it all happen well :)
If you were developing a thick client only style app then I wouldn't hold my
breath for 4.1. I would use hivemind + servlets to do the work. Probably
using json.org stuff to do the manipulations.
I'm doing tons of thick client application development myself right now and
am basically using the setup I just described. Of course I can't give
anything specific that I'm doing there back to the community directly, but I
am using the knowledge gained from doing it to try and create the best ajax
support in tapestry possible. I might also note that I'm working with a
couple of the top dojo comitters on these projects so whatever ends up in
tapestry I think will probably be very close to as good as it can get for
framework integration.
Whatever you guys come up with to contribute will be greatly appreciated
though.
I don't know what problems you had with tacos, as I find it very useful for
thin client style tapestry apps, but of course this won't work quite as well
for your thick needs.
I can't say for sure how I feel about the iterations and looping things that
you mentioned. If there is a hurdel to overcome I've probably already hit it
before in either tacos or my dojo work, so I'm not worried about what the
end result will be in tapestrys support of these concepts.
On 4/5/06, Sam Gendler <sg...@ideasculptor.com> wrote:
>
> OK, I like what I saw there, but I have some questions.
>
> 1. Your implementation still relies on explicitly stating which
> components will be updated by a particular request. What happens in
> the case of a component that was generated iteratively in a loop or
> table which needs to be updated?
>
> 2. What kind of timeframe are we talking about to get these changes
> built. I'm happy to join the development effort, and even task other
> members of my team to it, but I clearly have a lot to learn about
> tapestry internals. I could follow most of what you were writing
> about, but only just. I'll come up to speed quickly once I'm into it,
> but if you think this will be months, I need to pursue a faster
> solution myself.
>
> 3. Since I can involve 2 or 3 engineers in developing this (including
> myself, and I generally work as much as 2 or 3 people), would you be
> willing and able to act as something of a project manager and
> architect in order to make sure we do it right. If I thought that
> putting 3 engineers on this full time could get us solid working code
> in 2 or 3 weeks, I'd do it without a second thought, but we'd need
> your guidance to get it done. I don't know how much time you spend on
> tapestry development and what kind of prirority it is for you. I
> don't know that I could pay you for labor, but I could guarantee that
> all our work would go back to the tapestry community.
>
> My goal is to build out a framework, preferably something that can be
> part of Tapestry itself, such that it becomes as easy to build ajax
> components as it is to build static ones today. Clearly, that wasn't
> the case with Tacos, from your description of the hoops you had to
> jump through. But I've got a pretty sophisticated ui that I need to
> deliver by late July, so if I am not done with the infrastructural
> aspects and on to component and ui development within a month, I won't
> make it. Given that we are targeting a 'thick client' approach,
> moving data around but not interface elements, I am pretty sure I
> could get my second servlet hack working inside a month. It is less
> clear to me, mostly due to lack of knowledge, that we could implement
> your tapestry41 roadmap concepts in the same timeframe. But with your
> assurance that you think it is possible, I am willing to give it a
> shot. I'd much rather do work that benefits the community as a whole.
>
> --sam
>
>
> On 4/5/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> > http://wiki.apache.org/jakarta-tapestry/Tapestry41Roadmap
> >
> > I would take a look at the ajax sections outlined towards the bottom.
> This
> > work is already currently underway.
> >
> > On 4/5/06, Sam Gendler <sg...@ideasculptor.com> wrote:
> > >
> > > Ive been unable to sleep, of late, worrying about my ability to
> > > deliver a cutting edge, ajax enabled application from within Tapestry.
> > > I chose Tapestry as a framework before I had significant user
> > > experience, but after being utterly dissatisfied with the maturity of
> > > all other java component-based frameworks. However, the rewind cycle
> > > thing started to make me nervous as soon as I began to understand it,
> > > as a good ajax application really needs to be able to make requests
> > > back to the server that are independant of the content or structure of
> > > a page.
> > >
> > > I really like Tapestry's templates, which alow me to retain the
> > > general structure of the raw html so I can work with designers easily,
> > > and the support for internationalization is excellent, but the page
> > > orientation of all client-server communication was making me nervous.
> > > I believe, from some of the reading I've done, that the Tacos
> > > components that make async requests actually cause a full rewind on
> > > every request. More importantly, I couldn't imagine how I would
> > > support doing things like adding new form elements from javascript.
> > >
> > > I think I came up with a solution last night, but I can't be the only
> > > person thinking about this problem, so I thought I'd run it past folks
> > > here before writing it up in full and starting work on it. AT the
> > > very least, hopefully someone will clue me in on the correct way to
> > > handle this if my solution has holes in it that I am unaware of. So
> > > please, bring on the constructive criticism. Also, bear in mind that
> > > I don't have a very deep understanding of Tapestry internals yet, and
> > > my first task will be to delve under the hood and figure out how I
> > > would actually proceed, so I may make the occasional factual error
> > > below.
> > >
> > >
> > >
> > > There are a number of available tools for marshalling/unmarshalling
> > > java objects to and from xml (or JSON or anything else. I'm fairly
> > > agnostic on this one). The only issue is how to submit requests to the
> > > server and get back results without having to be concerned with page
> > > structure or doing lots of unnecessary work.
> > >
> > > The thought I had was to add a second servlet to my webapp, one which
> > > functions in a tapestry-esque manner (injecting services and
> > > properties, autopopulating properties based on request contents, use
> > > Tapestry annotations, etc), but which is 'stateless.' The Service (as
> > > opposed to a Page) would have properties populated according to some
> > > known scheme (in previous projects, I've used jakarta BeanUtils
> > > notation, ognl, Maps, and other tricks, and then a listener method
> > > would be called. The listener would either return an object which
> > > could be marshalled back as XML/JSON/text, or would write directly to
> > > the client. Of course, it would be easy to provide custom marshalling
> > > mechanisms for any given class that might be returned. All that would
> > > be required would be javascript in the page which knows how to parse
> > > the incoming data.
> > >
> > > Now, it is entirely possible that something like this could be built
> > > within the confines of a Tapestry Page, perhaps by providing a new
> > > Service, so my concept of a second servlet stems mostly from ignorance
> > > of what is available to me, currently.
> > >
> > > Regardless of the implementation details, the resulting app would be
> > > quite compelling, for me, and I suspect for others. We would get
> > > Tapestry's excellent templates/internationalization/infrastructure but
> > > all data i/o would occur via Services instead of Pages. When Page
> > > changes are required, and for simple forms, Tapestry Pages would still
> > > be very useful, but much of the business logic could migrate away from
> > > the Page rendering logic. Obviously, you'd have to be careful of the
> > > rewind cycle when dynamically adding new input fields to a page which
> > > might get submitted, but even that can be handled by submitting the
> > > new objects asynchronously and then re-requesting the page
> > > asynchronously, getting the browser version and the tapestry state
> > > back in sync.
> > >
> > > At any rate, in a full ajax app, it is unlikely that form data would
> > > ever be submitted back via a regular post, so it is probably a moot
> > > point for many, if not most 'Web 2.0' apps. There, I actually used the
> > > term. Ugh.
> > >
> > > These are just brief ramblings, as I have to run out, and I wanted to
> > > get my thoughts out there before I am away froma computer for most of
> > > the day.
> > >
> > > So please, feel free to take my idea apart, as I am sure I'll learn
> > > plenty in the process. In the end, so long as I can do ajax-y things
> > > within Tapestry, I don't care how I get there.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > --
> > Jesse Kuhnert
> > Tacos/Tapestry, team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind. http://opennotion.com
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://opennotion.com
Re: handling async xml requests in Tapestry - a proposal
Posted by Sam Gendler <sg...@ideasculptor.com>.
OK, I like what I saw there, but I have some questions.
1. Your implementation still relies on explicitly stating which
components will be updated by a particular request. What happens in
the case of a component that was generated iteratively in a loop or
table which needs to be updated?
2. What kind of timeframe are we talking about to get these changes
built. I'm happy to join the development effort, and even task other
members of my team to it, but I clearly have a lot to learn about
tapestry internals. I could follow most of what you were writing
about, but only just. I'll come up to speed quickly once I'm into it,
but if you think this will be months, I need to pursue a faster
solution myself.
3. Since I can involve 2 or 3 engineers in developing this (including
myself, and I generally work as much as 2 or 3 people), would you be
willing and able to act as something of a project manager and
architect in order to make sure we do it right. If I thought that
putting 3 engineers on this full time could get us solid working code
in 2 or 3 weeks, I'd do it without a second thought, but we'd need
your guidance to get it done. I don't know how much time you spend on
tapestry development and what kind of prirority it is for you. I
don't know that I could pay you for labor, but I could guarantee that
all our work would go back to the tapestry community.
My goal is to build out a framework, preferably something that can be
part of Tapestry itself, such that it becomes as easy to build ajax
components as it is to build static ones today. Clearly, that wasn't
the case with Tacos, from your description of the hoops you had to
jump through. But I've got a pretty sophisticated ui that I need to
deliver by late July, so if I am not done with the infrastructural
aspects and on to component and ui development within a month, I won't
make it. Given that we are targeting a 'thick client' approach,
moving data around but not interface elements, I am pretty sure I
could get my second servlet hack working inside a month. It is less
clear to me, mostly due to lack of knowledge, that we could implement
your tapestry41 roadmap concepts in the same timeframe. But with your
assurance that you think it is possible, I am willing to give it a
shot. I'd much rather do work that benefits the community as a whole.
--sam
On 4/5/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> http://wiki.apache.org/jakarta-tapestry/Tapestry41Roadmap
>
> I would take a look at the ajax sections outlined towards the bottom. This
> work is already currently underway.
>
> On 4/5/06, Sam Gendler <sg...@ideasculptor.com> wrote:
> >
> > Ive been unable to sleep, of late, worrying about my ability to
> > deliver a cutting edge, ajax enabled application from within Tapestry.
> > I chose Tapestry as a framework before I had significant user
> > experience, but after being utterly dissatisfied with the maturity of
> > all other java component-based frameworks. However, the rewind cycle
> > thing started to make me nervous as soon as I began to understand it,
> > as a good ajax application really needs to be able to make requests
> > back to the server that are independant of the content or structure of
> > a page.
> >
> > I really like Tapestry's templates, which alow me to retain the
> > general structure of the raw html so I can work with designers easily,
> > and the support for internationalization is excellent, but the page
> > orientation of all client-server communication was making me nervous.
> > I believe, from some of the reading I've done, that the Tacos
> > components that make async requests actually cause a full rewind on
> > every request. More importantly, I couldn't imagine how I would
> > support doing things like adding new form elements from javascript.
> >
> > I think I came up with a solution last night, but I can't be the only
> > person thinking about this problem, so I thought I'd run it past folks
> > here before writing it up in full and starting work on it. AT the
> > very least, hopefully someone will clue me in on the correct way to
> > handle this if my solution has holes in it that I am unaware of. So
> > please, bring on the constructive criticism. Also, bear in mind that
> > I don't have a very deep understanding of Tapestry internals yet, and
> > my first task will be to delve under the hood and figure out how I
> > would actually proceed, so I may make the occasional factual error
> > below.
> >
> >
> >
> > There are a number of available tools for marshalling/unmarshalling
> > java objects to and from xml (or JSON or anything else. I'm fairly
> > agnostic on this one). The only issue is how to submit requests to the
> > server and get back results without having to be concerned with page
> > structure or doing lots of unnecessary work.
> >
> > The thought I had was to add a second servlet to my webapp, one which
> > functions in a tapestry-esque manner (injecting services and
> > properties, autopopulating properties based on request contents, use
> > Tapestry annotations, etc), but which is 'stateless.' The Service (as
> > opposed to a Page) would have properties populated according to some
> > known scheme (in previous projects, I've used jakarta BeanUtils
> > notation, ognl, Maps, and other tricks, and then a listener method
> > would be called. The listener would either return an object which
> > could be marshalled back as XML/JSON/text, or would write directly to
> > the client. Of course, it would be easy to provide custom marshalling
> > mechanisms for any given class that might be returned. All that would
> > be required would be javascript in the page which knows how to parse
> > the incoming data.
> >
> > Now, it is entirely possible that something like this could be built
> > within the confines of a Tapestry Page, perhaps by providing a new
> > Service, so my concept of a second servlet stems mostly from ignorance
> > of what is available to me, currently.
> >
> > Regardless of the implementation details, the resulting app would be
> > quite compelling, for me, and I suspect for others. We would get
> > Tapestry's excellent templates/internationalization/infrastructure but
> > all data i/o would occur via Services instead of Pages. When Page
> > changes are required, and for simple forms, Tapestry Pages would still
> > be very useful, but much of the business logic could migrate away from
> > the Page rendering logic. Obviously, you'd have to be careful of the
> > rewind cycle when dynamically adding new input fields to a page which
> > might get submitted, but even that can be handled by submitting the
> > new objects asynchronously and then re-requesting the page
> > asynchronously, getting the browser version and the tapestry state
> > back in sync.
> >
> > At any rate, in a full ajax app, it is unlikely that form data would
> > ever be submitted back via a regular post, so it is probably a moot
> > point for many, if not most 'Web 2.0' apps. There, I actually used the
> > term. Ugh.
> >
> > These are just brief ramblings, as I have to run out, and I wanted to
> > get my thoughts out there before I am away froma computer for most of
> > the day.
> >
> > So please, feel free to take my idea apart, as I am sure I'll learn
> > plenty in the process. In the end, so long as I can do ajax-y things
> > within Tapestry, I don't care how I get there.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://opennotion.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: handling async xml requests in Tapestry - a proposal
Posted by Jesse Kuhnert <jk...@gmail.com>.
http://wiki.apache.org/jakarta-tapestry/Tapestry41Roadmap
I would take a look at the ajax sections outlined towards the bottom. This
work is already currently underway.
On 4/5/06, Sam Gendler <sg...@ideasculptor.com> wrote:
>
> Ive been unable to sleep, of late, worrying about my ability to
> deliver a cutting edge, ajax enabled application from within Tapestry.
> I chose Tapestry as a framework before I had significant user
> experience, but after being utterly dissatisfied with the maturity of
> all other java component-based frameworks. However, the rewind cycle
> thing started to make me nervous as soon as I began to understand it,
> as a good ajax application really needs to be able to make requests
> back to the server that are independant of the content or structure of
> a page.
>
> I really like Tapestry's templates, which alow me to retain the
> general structure of the raw html so I can work with designers easily,
> and the support for internationalization is excellent, but the page
> orientation of all client-server communication was making me nervous.
> I believe, from some of the reading I've done, that the Tacos
> components that make async requests actually cause a full rewind on
> every request. More importantly, I couldn't imagine how I would
> support doing things like adding new form elements from javascript.
>
> I think I came up with a solution last night, but I can't be the only
> person thinking about this problem, so I thought I'd run it past folks
> here before writing it up in full and starting work on it. AT the
> very least, hopefully someone will clue me in on the correct way to
> handle this if my solution has holes in it that I am unaware of. So
> please, bring on the constructive criticism. Also, bear in mind that
> I don't have a very deep understanding of Tapestry internals yet, and
> my first task will be to delve under the hood and figure out how I
> would actually proceed, so I may make the occasional factual error
> below.
>
>
>
> There are a number of available tools for marshalling/unmarshalling
> java objects to and from xml (or JSON or anything else. I'm fairly
> agnostic on this one). The only issue is how to submit requests to the
> server and get back results without having to be concerned with page
> structure or doing lots of unnecessary work.
>
> The thought I had was to add a second servlet to my webapp, one which
> functions in a tapestry-esque manner (injecting services and
> properties, autopopulating properties based on request contents, use
> Tapestry annotations, etc), but which is 'stateless.' The Service (as
> opposed to a Page) would have properties populated according to some
> known scheme (in previous projects, I've used jakarta BeanUtils
> notation, ognl, Maps, and other tricks, and then a listener method
> would be called. The listener would either return an object which
> could be marshalled back as XML/JSON/text, or would write directly to
> the client. Of course, it would be easy to provide custom marshalling
> mechanisms for any given class that might be returned. All that would
> be required would be javascript in the page which knows how to parse
> the incoming data.
>
> Now, it is entirely possible that something like this could be built
> within the confines of a Tapestry Page, perhaps by providing a new
> Service, so my concept of a second servlet stems mostly from ignorance
> of what is available to me, currently.
>
> Regardless of the implementation details, the resulting app would be
> quite compelling, for me, and I suspect for others. We would get
> Tapestry's excellent templates/internationalization/infrastructure but
> all data i/o would occur via Services instead of Pages. When Page
> changes are required, and for simple forms, Tapestry Pages would still
> be very useful, but much of the business logic could migrate away from
> the Page rendering logic. Obviously, you'd have to be careful of the
> rewind cycle when dynamically adding new input fields to a page which
> might get submitted, but even that can be handled by submitting the
> new objects asynchronously and then re-requesting the page
> asynchronously, getting the browser version and the tapestry state
> back in sync.
>
> At any rate, in a full ajax app, it is unlikely that form data would
> ever be submitted back via a regular post, so it is probably a moot
> point for many, if not most 'Web 2.0' apps. There, I actually used the
> term. Ugh.
>
> These are just brief ramblings, as I have to run out, and I wanted to
> get my thoughts out there before I am away froma computer for most of
> the day.
>
> So please, feel free to take my idea apart, as I am sure I'll learn
> plenty in the process. In the end, so long as I can do ajax-y things
> within Tapestry, I don't care how I get there.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://opennotion.com