You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Dan Adams <da...@ifactory.com> on 2005/12/01 19:43:14 UTC
daydreaming of tapetry and ajax
Excuse my daydreaming for a minute here. I know that same ajax
components exist (and I have not yet personally gotten into them so
forgive me) but what I'm thinking that it might be cool to have a way to
easily develop full ajax interfaces rather than just using a few ajax
components within pages in a normal request/response type cycle. Are we
on our way to this already? I think think it would be SO cool if
tapestry could be the first framework to really offer a way of easily
developing full ajax apps in the way that it enables easy development
now. I mean, more and more you see apps popping up that are ajax based
and there are a few javascript libraries out there for doing ajax stuff
easier but even so I don't think that this means ajax app development is
by no means 'easy'. Am I the only one or would it not be super cool to
be able to use tapestry to develop ajax apps that are almost like normal
gui apps for the web? Is this something that could be accomplished with
an additional library or is it so much of a change that it warrants a
new framework?
--
Dan Adams
Software Engineer
Interactive Factory
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: daydreaming of tapetry and ajax
Posted by Jesse Kuhnert <jk...@gmail.com>.
I think this is exactly why the recent vote happened to get me added on to
Tapestry as a committer.
This is exactly where I personally want to go. (more or less). You hit the
nail on the head though, all of these frameworks are nice, and it's nice
that they have "ajax support", but it really belongs in the framework
proper. Transparent(more or less) and easy to use by everyone. This is the
only thing I want to do with my commit privileges (i think I will probably
fix some bugs here and there too just to provide some support) in tapestry
to start with.
I really have evaluated the other frameworks (java based) to find the best
one to contribute this kind of effort to, and Tapestry is still the winner
hands down :) It supports all of the things that will make what you describe
possible already, with a minor tweak here or there, which goes to show that
it was built with design quality in mind the whole time, not being
constrained by specifications, or misguided principles of "simplicity" or
whatever other nonsense I've been reading elsewhere.
Anyways, I'm very excited that someone else is thinking this way too :) We
should start a new wiki page somewhere so that more people can brainstorm
and share their thoughts on where this should go. I've already got a number
of pretty cool ajax app development utilities in tacos that will make doing
this with tapestry even easier.
jesse
On 12/1/05, Dan Adams <da...@ifactory.com> wrote:
>
> Excuse my daydreaming for a minute here. I know that same ajax
> components exist (and I have not yet personally gotten into them so
> forgive me) but what I'm thinking that it might be cool to have a way to
> easily develop full ajax interfaces rather than just using a few ajax
> components within pages in a normal request/response type cycle. Are we
> on our way to this already? I think think it would be SO cool if
> tapestry could be the first framework to really offer a way of easily
> developing full ajax apps in the way that it enables easy development
> now. I mean, more and more you see apps popping up that are ajax based
> and there are a few javascript libraries out there for doing ajax stuff
> easier but even so I don't think that this means ajax app development is
> by no means 'easy'. Am I the only one or would it not be super cool to
> be able to use tapestry to develop ajax apps that are almost like normal
> gui apps for the web? Is this something that could be accomplished with
> an additional library or is it so much of a change that it warrants a
> new framework?
>
> --
> Dan Adams
> Software Engineer
> Interactive Factory
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: daydreaming of tapetry and ajax
Posted by Jesse Kuhnert <jk...@gmail.com>.
Not very far at all :) Most of the impl has already been done, it will need
to be completely re-done the new way, but that's just monkeys typing on a
keyboard.
The design is all sitting up in my head. I just need subversion access and a
reasonable plan/ok from the general community and we're off :)
On 12/1/05, Dan Adams <da...@ifactory.com> wrote:
>
> very rough estimate, how far do you think tacos and tapestry are from
> this kind of thing? what are the major limitations blocking it?
>
> On Thu, 2005-12-01 at 15:31 -0500, Jesse Kuhnert wrote:
> > I think the tacos4 approach has changed from 3.0.3 in kind of an apples
> and
> > oranges sort of way. The things you mentioned are being addressed:
> >
> > -) The only area in tacos that requires people to acknowledge javascript
> > code is the ProgressBar.
> >
> > -) All exceptions, client-side AND server side are being handled in a
> very
> > transparent and easy way in tacos. Any server exception will pop open a
> > FloatingPane with all of the gory details.
> >
> > -) The debug console makes debugging what's going on as easy as
> debugging
> > anything else in java. The javascript framework that we're using, dojo,
> has
> > a built-in logging backbone similar to log4j in the way that it let's
> you
> > control things. The debug console utilizes this to provide a
> FloatingWindow
> > (hideable or showable, also supports clearing log entries/color coded
> log
> > message types, etc..) that makes this much much easier to work with.
> >
> > I don't agree with completely about Tapestry only being able to support
> the
> > concept of pages. I think the portlet code is a very good example.
> In fact
> > I think the internals of tapestry look more like swing code than any
> other
> > web framework I've seen thus far, and if you've ever done a lot of swing
> > (rendering with Graphics) objects you'll know what I'm talking about.
> This
> > is the largest part that I would like to focus on with tapestry. It
> already
> > supports direct renders of "areas", save for one tiny little part, which
> are
> > Loops. This is already being addressed so I'm fairly confident we'll be
> > seeing some very impressive new functionality soon-ish.
> >
> > My last and final point would be that a very large and driving goal
> behind
> > tacos has been to eliminate the need for anyone to understand what any
> > javascript has been doing on the page, as well as what's involved in
> most of
> > the process. I think what's sitting in cvs head for tacos4 right now
> does a
> > pretty good job of doing that.
> >
> > The other part(ok so one more point) that gives me a great deal of
> > confidence is that tacos has tried, in every circumstance to defer all
> > javascript to the http://dojotoolkit.org javascript library. That makes
> our
> > risk of introducing bugs/ability to quickly move forward much easier
> than
> > lots of custom javascript.
> >
> > It's also funny that you mentioned some of the big names around who has
> been
> > working with ajax. I think everyone would be very surprised/relieved to
> > learn just who exactly is using the library(dojo) as well as who
> actively
> > develops it's contents. I can't say(or even know) all the players
> involved,
> > but if anyone is familiar with Flickr, one of the original pioneers of
> the
> > whole "web 2.0" style of doing things (ajax included) you'd be happy to
> know
> > that one of their lead developers is also an active contributor to that
> > library. Basically, dojo has an intensely
> > dedicated/knowledgeable/experienced set of industry leaders driving it's
> > development, which I personally think makes it the best choice
> around...I'm
> > just happy that tacos has been able to bridge the two worlds somewhat.
> >
> > jesse
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: daydreaming of tapetry and ajax
Posted by Dan Adams <da...@ifactory.com>.
very rough estimate, how far do you think tacos and tapestry are from
this kind of thing? what are the major limitations blocking it?
On Thu, 2005-12-01 at 15:31 -0500, Jesse Kuhnert wrote:
> I think the tacos4 approach has changed from 3.0.3 in kind of an apples and
> oranges sort of way. The things you mentioned are being addressed:
>
> -) The only area in tacos that requires people to acknowledge javascript
> code is the ProgressBar.
>
> -) All exceptions, client-side AND server side are being handled in a very
> transparent and easy way in tacos. Any server exception will pop open a
> FloatingPane with all of the gory details.
>
> -) The debug console makes debugging what's going on as easy as debugging
> anything else in java. The javascript framework that we're using, dojo, has
> a built-in logging backbone similar to log4j in the way that it let's you
> control things. The debug console utilizes this to provide a FloatingWindow
> (hideable or showable, also supports clearing log entries/color coded log
> message types, etc..) that makes this much much easier to work with.
>
> I don't agree with completely about Tapestry only being able to support the
> concept of pages. I think the portlet code is a very good example. In fact
> I think the internals of tapestry look more like swing code than any other
> web framework I've seen thus far, and if you've ever done a lot of swing
> (rendering with Graphics) objects you'll know what I'm talking about. This
> is the largest part that I would like to focus on with tapestry. It already
> supports direct renders of "areas", save for one tiny little part, which are
> Loops. This is already being addressed so I'm fairly confident we'll be
> seeing some very impressive new functionality soon-ish.
>
> My last and final point would be that a very large and driving goal behind
> tacos has been to eliminate the need for anyone to understand what any
> javascript has been doing on the page, as well as what's involved in most of
> the process. I think what's sitting in cvs head for tacos4 right now does a
> pretty good job of doing that.
>
> The other part(ok so one more point) that gives me a great deal of
> confidence is that tacos has tried, in every circumstance to defer all
> javascript to the http://dojotoolkit.org javascript library. That makes our
> risk of introducing bugs/ability to quickly move forward much easier than
> lots of custom javascript.
>
> It's also funny that you mentioned some of the big names around who has been
> working with ajax. I think everyone would be very surprised/relieved to
> learn just who exactly is using the library(dojo) as well as who actively
> develops it's contents. I can't say(or even know) all the players involved,
> but if anyone is familiar with Flickr, one of the original pioneers of the
> whole "web 2.0" style of doing things (ajax included) you'd be happy to know
> that one of their lead developers is also an active contributor to that
> library. Basically, dojo has an intensely
> dedicated/knowledgeable/experienced set of industry leaders driving it's
> development, which I personally think makes it the best choice around...I'm
> just happy that tacos has been able to bridge the two worlds somewhat.
>
> jesse
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: daydreaming of tapetry and ajax
Posted by Jesse Kuhnert <jk...@gmail.com>.
I think the tacos4 approach has changed from 3.0.3 in kind of an apples and
oranges sort of way. The things you mentioned are being addressed:
-) The only area in tacos that requires people to acknowledge javascript
code is the ProgressBar.
-) All exceptions, client-side AND server side are being handled in a very
transparent and easy way in tacos. Any server exception will pop open a
FloatingPane with all of the gory details.
-) The debug console makes debugging what's going on as easy as debugging
anything else in java. The javascript framework that we're using, dojo, has
a built-in logging backbone similar to log4j in the way that it let's you
control things. The debug console utilizes this to provide a FloatingWindow
(hideable or showable, also supports clearing log entries/color coded log
message types, etc..) that makes this much much easier to work with.
I don't agree with completely about Tapestry only being able to support the
concept of pages. I think the portlet code is a very good example. In fact
I think the internals of tapestry look more like swing code than any other
web framework I've seen thus far, and if you've ever done a lot of swing
(rendering with Graphics) objects you'll know what I'm talking about. This
is the largest part that I would like to focus on with tapestry. It already
supports direct renders of "areas", save for one tiny little part, which are
Loops. This is already being addressed so I'm fairly confident we'll be
seeing some very impressive new functionality soon-ish.
My last and final point would be that a very large and driving goal behind
tacos has been to eliminate the need for anyone to understand what any
javascript has been doing on the page, as well as what's involved in most of
the process. I think what's sitting in cvs head for tacos4 right now does a
pretty good job of doing that.
The other part(ok so one more point) that gives me a great deal of
confidence is that tacos has tried, in every circumstance to defer all
javascript to the http://dojotoolkit.org javascript library. That makes our
risk of introducing bugs/ability to quickly move forward much easier than
lots of custom javascript.
It's also funny that you mentioned some of the big names around who has been
working with ajax. I think everyone would be very surprised/relieved to
learn just who exactly is using the library(dojo) as well as who actively
develops it's contents. I can't say(or even know) all the players involved,
but if anyone is familiar with Flickr, one of the original pioneers of the
whole "web 2.0" style of doing things (ajax included) you'd be happy to know
that one of their lead developers is also an active contributor to that
library. Basically, dojo has an intensely
dedicated/knowledgeable/experienced set of industry leaders driving it's
development, which I personally think makes it the best choice around...I'm
just happy that tacos has been able to bridge the two worlds somewhat.
jesse
On 12/1/05, Patrick Casey <pa...@adelphia.net> wrote:
>
>
> I really want to like AJAX as a more general case solution, but
> I'm
> with Konstantin on this one. It's got a *whole lot* of loosely coupled
> moving parts that all have to work together seamlessly in order to produce
> the desired output.
>
> Framework tools like Tacos or DWR help by hiding a lot of the
> moving
> parts, but they also restrict what you're doing to those things the
> framework designers had in mind. For the 99% use case, this is where the
> tools are going to have to evolve if normal humans are going to work with
> them. Trying to build an AJAX app from the ground up where you're writing
> both the javascript and the server side code is buying a world of pain as:
>
> 1) You've got to write in two different languages.
> 2) One of the languages (the javascript) has poor debugging
> capabilities (the best I've found yet is the venkman debugger an it's
> still
> flakey).
> 3) Any change you make has to be done in both places.
> 4) The underlying transport layer (XML over HTTP) has no error
> handling at all except for wire errors so if, for example, your server
> dumps, your client has no clue and it'll just sit there unless you code
> in,
> say, a heartbeat timer, etc.
>
> The whole point is that "raw" AJAX, imho at least, is *way*, *way*
> too complicated to be productive. It took a whole *host* of developers at
> Google, what, two years to get google maps working? And it has all of *one
> screen* :). Which means a component based architecture (where an ajax
> expert
> can build a reusable piece of code), is a much better approach.
>
> The one concern with this approach I have vis-à-vis tapestry is
> that
> AJAX is all about taking little "nibbles" out of a page e.g. I want to
> submit just *part* of a form, or I want to replace "click here to search"
> with an actual search form that comes up from the server.
>
> Tapestry though, is architected around the concept of whole page
> rendering. One can't guarantee that a component will render properly
> outside
> of the context of its page. Which means, even if I only want to refresh
> 1/100th of a page, I still need to render the whole thing on the server,
> trim out the part I want to refresh, and push that back to the client. So
> I
> cut down on my wire traffic, and I save the user a page load, *but* the
> server is still building a full page.
>
> Maybe the Tacos lads have found some clever ways to mitigate this
> in
> the newer libraries, but last time I checked (the 3.0.3 libraries), I
> didn't
> see an easy alterative to this approach.
>
> --- Pat
>
> > -----Original Message-----
> > From: Konstantin Ignatyev [mailto:kgignatyev@yahoo.com]
> > Sent: Thursday, December 01, 2005 11:43 AM
> > To: Tapestry users
> > Subject: Re: daydreaming of tapetry and ajax
> >
> > Neither do I.
> > Ajax has it place, but it is relatively small IMO and
> > Ajax is not good in many cases even seems like good
> > choice.
> >
> >
> > --- Jesse Kuhnert <jk...@gmail.com> wrote:
> >
> > > http://www.w3.org/2006/webapi/
> > >
> > > I don't think ajax is going away anytime soon ;)
> > >
> > > On 12/1/05, Konstantin Ignatyev
> > > <kg...@yahoo.com> wrote:
> > > >
> > > > I think you and many AJAX fans need a cold shower
> > > :)
> > > >
> > > >
> > >
> > http://www.theserverside.com/news/thread.tss?thread_id=37106#187945
> > > >
> > > >
> > > > --- Dan Adams <da...@ifactory.com> wrote:
> > > >
> > > > > Excuse my daydreaming for a minute here. I know
> > > that
> > > > > same ajax
> > > > > components exist (and I have not yet personally
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: daydreaming of tapetry and ajax
Posted by Jesse Kuhnert <jk...@gmail.com>.
You could start by taking a look at the new tacos library :)
On 12/1/05, Patrick Casey <pa...@adelphia.net> wrote:
>
>
> At this point I'm not trying to be argumentative; I'm honestly
> curious. Having looked into the partial render code in Tacos 3.0.3, I know
> it was still hamstrung by the independence limitation (hence the need to
> define your own partial elements to flag dependence/independence for the
> xml
> layer).
>
> So I'm trying to figure out how you solved the problem without
> providing *some* form of extra information to the xml library.
>
> --- Pat
>
> > -----Original Message-----
> > From: Jesse Kuhnert [mailto:jkuhnert@gmail.com]
> > Sent: Thursday, December 01, 2005 2:01 PM
> > To: Tapestry users
> > Subject: Re: daydreaming of tapetry and ajax
> >
> > Ughh,....In the interest of productivity I will refrain from trying to
> > give
> > a good response until later, but I will say that you are making an awful
> > lot
> > of assumptions about how the partial render model should/will work. Esp
> of
> > those involved with Forms and loops.
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
RE: daydreaming of tapetry and ajax
Posted by Patrick Casey <pa...@adelphia.net>.
At this point I'm not trying to be argumentative; I'm honestly
curious. Having looked into the partial render code in Tacos 3.0.3, I know
it was still hamstrung by the independence limitation (hence the need to
define your own partial elements to flag dependence/independence for the xml
layer).
So I'm trying to figure out how you solved the problem without
providing *some* form of extra information to the xml library.
--- Pat
> -----Original Message-----
> From: Jesse Kuhnert [mailto:jkuhnert@gmail.com]
> Sent: Thursday, December 01, 2005 2:01 PM
> To: Tapestry users
> Subject: Re: daydreaming of tapetry and ajax
>
> Ughh,....In the interest of productivity I will refrain from trying to
> give
> a good response until later, but I will say that you are making an awful
> lot
> of assumptions about how the partial render model should/will work. Esp of
> those involved with Forms and loops.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: daydreaming of tapetry and ajax
Posted by Jesse Kuhnert <jk...@gmail.com>.
Ughh,....In the interest of productivity I will refrain from trying to give
a good response until later, but I will say that you are making an awful lot
of assumptions about how the partial render model should/will work. Esp of
those involved with Forms and loops.
On 12/1/05, Patrick Casey <pa...@adelphia.net> wrote:
>
>
> How's it just going to work? I can break component independence
> with
> as simple a line of code as:
>
> protected void renderComponent(IMarkupWriter writer, IRequestCycle cycle)
> {
> IForm currentForm = getForm(cycle);
> String currentComponentId = currentForm.getElementId();
> }
>
> That's the way all the OOB form components generate their
> component
> IDs, and it's guaranteed not to work in a partial render (in the special
> case of a form with no dynamic elements, it might be determinable by
> introspecting the component tree, but that's a lot of work for a special
> case solution).
>
> Or did some sort of major overhaul of the compoment naming scheme
> take place in 4.0? Even then, I can still write a component which calls
> getPage().doSomething() in which case my component is lost without the
> page...
>
> --- Pat
>
> > -----Original Message-----
> > From: Jesse Kuhnert [mailto:jkuhnert@gmail.com]
> > Sent: Thursday, December 01, 2005 1:05 PM
> > To: Tapestry users
> > Subject: Re: daydreaming of tapetry and ajax
> >
> > It's all because of Tapestry's/hivemind wonderful binding parameter
> > infrastructure. You really can do this, and the components ~don't~ need
> to
> > be completely self contained. It just works :)
> >
> > I think the interfaces/IRequestCycle/base classes all provide more than
> > enough for this functionality to also "just work". There are more ideal
> > new
> > concepts that I'd like to introduce, but overall the framework really
> does
> > support these things as is. It just needs an ever so slight change here
> or
> > there to make it possbile. I promise, it really is possible. You will
> see
> > :)
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
RE: daydreaming of tapetry and ajax
Posted by Patrick Casey <pa...@adelphia.net>.
How's it just going to work? I can break component independence with
as simple a line of code as:
protected void renderComponent(IMarkupWriter writer, IRequestCycle cycle)
{
IForm currentForm = getForm(cycle);
String currentComponentId = currentForm.getElementId();
}
That's the way all the OOB form components generate their component
IDs, and it's guaranteed not to work in a partial render (in the special
case of a form with no dynamic elements, it might be determinable by
introspecting the component tree, but that's a lot of work for a special
case solution).
Or did some sort of major overhaul of the compoment naming scheme
take place in 4.0? Even then, I can still write a component which calls
getPage().doSomething() in which case my component is lost without the
page...
--- Pat
> -----Original Message-----
> From: Jesse Kuhnert [mailto:jkuhnert@gmail.com]
> Sent: Thursday, December 01, 2005 1:05 PM
> To: Tapestry users
> Subject: Re: daydreaming of tapetry and ajax
>
> It's all because of Tapestry's/hivemind wonderful binding parameter
> infrastructure. You really can do this, and the components ~don't~ need to
> be completely self contained. It just works :)
>
> I think the interfaces/IRequestCycle/base classes all provide more than
> enough for this functionality to also "just work". There are more ideal
> new
> concepts that I'd like to introduce, but overall the framework really does
> support these things as is. It just needs an ever so slight change here or
> there to make it possbile. I promise, it really is possible. You will see
> :)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: daydreaming of tapetry and ajax
Posted by Jesse Kuhnert <jk...@gmail.com>.
It's all because of Tapestry's/hivemind wonderful binding parameter
infrastructure. You really can do this, and the components ~don't~ need to
be completely self contained. It just works :)
I think the interfaces/IRequestCycle/base classes all provide more than
enough for this functionality to also "just work". There are more ideal new
concepts that I'd like to introduce, but overall the framework really does
support these things as is. It just needs an ever so slight change here or
there to make it possbile. I promise, it really is possible. You will see :)
On 12/1/05, Patrick Casey <pa...@adelphia.net> wrote:
>
>
> It's not a case so much that a component is guaranteed *not* to
> render on it's own, it's more a case that it's not guaranteed that it
> *will*. Outside of a page context, some components will render just
> peachy.
> Others will fail.
>
> It all comes down to whether or not your page depends on data
> prepped elsewhere in the page render. You using an odd/even bean to change
> color? Well, that bean won't be set properly in a component-only render.
> Your component drawing based on data that the page pulled out of the DB?
> That data won't be there in a component-only render, etc. Some components
> though, which are totally self contained, can render just fine in a
> partial-render situation.
>
> It strikes me that this isn't particularly problematic e.g. it's
> reasonable that some use cases require a full page, but others do not. I
> think what tapestry needs to do is define a way to *identify* a discrete,
> as
> opposed to page-dependant component. I'd think this is something the
> component designer could set as a flag that Tapestry (and things like
> Tacos)
> could then use to determine how to re-render the component. (another
> useful
> flag would be "cacheable" to identify a component which renders repeatably
> and hence could be cached by the framework).
>
> Right now though, absent external information, the framework has
> to
> assume everything requires a full page render. Some things, like the
> portlet
> code, can assume otherwise, but that's precisely because they *know* it's
> a
> portlet and hence has to obey certain rules. A generic component on a
> generic page is an unknown quantity though and hence Tapestry has to
> assume
> the most conservative case.
>
> --- Pat
>
>
>
> > -----Original Message-----
> > From: Leonardo Quijano Vincenzi [mailto:leonardo@dtqsoftware.com]
> > Sent: Thursday, December 01, 2005 12:35 PM
> > To: Tapestry users
> > Subject: Re: daydreaming of tapetry and ajax
> >
> > Patrick Casey wrote:
> > > Tapestry though, is architected around the concept of whole page
> > > rendering. One can't guarantee that a component will render properly
> > outside
> > > of the context of its page. Which means, even if I only want to
> refresh
> > > 1/100th of a page, I still need to render the whole thing on the
> server,
> > > trim out the part I want to refresh, and push that back to the client.
> > So I
> > > cut down on my wire traffic, and I save the user a page load, *but*
> the
> > > server is still building a full page.
> > >
> > This is an important limitation of Tapestry component model that should
> > be targeted, if true, don't you think? I mean, a component - by
> > definition - is a black box. A component that depends on its container
> > page being rendered for proper rendering breaches that encapsulation
> > (note that this is different of just a component who needs its container
> > page to *exist* for proper rendering - in this case we don't have to
> > render the whole page, just to have it in memory).
> >
> > I was talking about this in the Tacos list. Components, should IMO, be
> > rendereable on their own, instead of needing the full page render cycle
> > to work. A server-side component model in memory would help in this
> > respect, I think.
> >
> > --
> > Ing. Leonardo Quijano Vincenzi
> > DTQ Software
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
RE: daydreaming of tapetry and ajax
Posted by Patrick Casey <pa...@adelphia.net>.
It's not a case so much that a component is guaranteed *not* to
render on it's own, it's more a case that it's not guaranteed that it
*will*. Outside of a page context, some components will render just peachy.
Others will fail.
It all comes down to whether or not your page depends on data
prepped elsewhere in the page render. You using an odd/even bean to change
color? Well, that bean won't be set properly in a component-only render.
Your component drawing based on data that the page pulled out of the DB?
That data won't be there in a component-only render, etc. Some components
though, which are totally self contained, can render just fine in a
partial-render situation.
It strikes me that this isn't particularly problematic e.g. it's
reasonable that some use cases require a full page, but others do not. I
think what tapestry needs to do is define a way to *identify* a discrete, as
opposed to page-dependant component. I'd think this is something the
component designer could set as a flag that Tapestry (and things like Tacos)
could then use to determine how to re-render the component. (another useful
flag would be "cacheable" to identify a component which renders repeatably
and hence could be cached by the framework).
Right now though, absent external information, the framework has to
assume everything requires a full page render. Some things, like the portlet
code, can assume otherwise, but that's precisely because they *know* it's a
portlet and hence has to obey certain rules. A generic component on a
generic page is an unknown quantity though and hence Tapestry has to assume
the most conservative case.
--- Pat
> -----Original Message-----
> From: Leonardo Quijano Vincenzi [mailto:leonardo@dtqsoftware.com]
> Sent: Thursday, December 01, 2005 12:35 PM
> To: Tapestry users
> Subject: Re: daydreaming of tapetry and ajax
>
> Patrick Casey wrote:
> > Tapestry though, is architected around the concept of whole page
> > rendering. One can't guarantee that a component will render properly
> outside
> > of the context of its page. Which means, even if I only want to refresh
> > 1/100th of a page, I still need to render the whole thing on the server,
> > trim out the part I want to refresh, and push that back to the client.
> So I
> > cut down on my wire traffic, and I save the user a page load, *but* the
> > server is still building a full page.
> >
> This is an important limitation of Tapestry component model that should
> be targeted, if true, don't you think? I mean, a component - by
> definition - is a black box. A component that depends on its container
> page being rendered for proper rendering breaches that encapsulation
> (note that this is different of just a component who needs its container
> page to *exist* for proper rendering - in this case we don't have to
> render the whole page, just to have it in memory).
>
> I was talking about this in the Tacos list. Components, should IMO, be
> rendereable on their own, instead of needing the full page render cycle
> to work. A server-side component model in memory would help in this
> respect, I think.
>
> --
> Ing. Leonardo Quijano Vincenzi
> DTQ Software
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: daydreaming of tapetry and ajax
Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
Patrick Casey wrote:
> Tapestry though, is architected around the concept of whole page
> rendering. One can't guarantee that a component will render properly outside
> of the context of its page. Which means, even if I only want to refresh
> 1/100th of a page, I still need to render the whole thing on the server,
> trim out the part I want to refresh, and push that back to the client. So I
> cut down on my wire traffic, and I save the user a page load, *but* the
> server is still building a full page.
>
This is an important limitation of Tapestry component model that should
be targeted, if true, don't you think? I mean, a component - by
definition - is a black box. A component that depends on its container
page being rendered for proper rendering breaches that encapsulation
(note that this is different of just a component who needs its container
page to *exist* for proper rendering - in this case we don't have to
render the whole page, just to have it in memory).
I was talking about this in the Tacos list. Components, should IMO, be
rendereable on their own, instead of needing the full page render cycle
to work. A server-side component model in memory would help in this
respect, I think.
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: daydreaming of tapetry and ajax
Posted by Patrick Casey <pa...@adelphia.net>.
I really want to like AJAX as a more general case solution, but I'm
with Konstantin on this one. It's got a *whole lot* of loosely coupled
moving parts that all have to work together seamlessly in order to produce
the desired output.
Framework tools like Tacos or DWR help by hiding a lot of the moving
parts, but they also restrict what you're doing to those things the
framework designers had in mind. For the 99% use case, this is where the
tools are going to have to evolve if normal humans are going to work with
them. Trying to build an AJAX app from the ground up where you're writing
both the javascript and the server side code is buying a world of pain as:
1) You've got to write in two different languages.
2) One of the languages (the javascript) has poor debugging
capabilities (the best I've found yet is the venkman debugger an it's still
flakey).
3) Any change you make has to be done in both places.
4) The underlying transport layer (XML over HTTP) has no error
handling at all except for wire errors so if, for example, your server
dumps, your client has no clue and it'll just sit there unless you code in,
say, a heartbeat timer, etc.
The whole point is that "raw" AJAX, imho at least, is *way*, *way*
too complicated to be productive. It took a whole *host* of developers at
Google, what, two years to get google maps working? And it has all of *one
screen* :). Which means a component based architecture (where an ajax expert
can build a reusable piece of code), is a much better approach.
The one concern with this approach I have vis-à-vis tapestry is that
AJAX is all about taking little "nibbles" out of a page e.g. I want to
submit just *part* of a form, or I want to replace "click here to search"
with an actual search form that comes up from the server.
Tapestry though, is architected around the concept of whole page
rendering. One can't guarantee that a component will render properly outside
of the context of its page. Which means, even if I only want to refresh
1/100th of a page, I still need to render the whole thing on the server,
trim out the part I want to refresh, and push that back to the client. So I
cut down on my wire traffic, and I save the user a page load, *but* the
server is still building a full page.
Maybe the Tacos lads have found some clever ways to mitigate this in
the newer libraries, but last time I checked (the 3.0.3 libraries), I didn't
see an easy alterative to this approach.
--- Pat
> -----Original Message-----
> From: Konstantin Ignatyev [mailto:kgignatyev@yahoo.com]
> Sent: Thursday, December 01, 2005 11:43 AM
> To: Tapestry users
> Subject: Re: daydreaming of tapetry and ajax
>
> Neither do I.
> Ajax has it place, but it is relatively small IMO and
> Ajax is not good in many cases even seems like good
> choice.
>
>
> --- Jesse Kuhnert <jk...@gmail.com> wrote:
>
> > http://www.w3.org/2006/webapi/
> >
> > I don't think ajax is going away anytime soon ;)
> >
> > On 12/1/05, Konstantin Ignatyev
> > <kg...@yahoo.com> wrote:
> > >
> > > I think you and many AJAX fans need a cold shower
> > :)
> > >
> > >
> >
> http://www.theserverside.com/news/thread.tss?thread_id=37106#187945
> > >
> > >
> > > --- Dan Adams <da...@ifactory.com> wrote:
> > >
> > > > Excuse my daydreaming for a minute here. I know
> > that
> > > > same ajax
> > > > components exist (and I have not yet personally
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: daydreaming of tapetry and ajax
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
Neither do I.
Ajax has it place, but it is relatively small IMO and
Ajax is not good in many cases even seems like good
choice.
--- Jesse Kuhnert <jk...@gmail.com> wrote:
> http://www.w3.org/2006/webapi/
>
> I don't think ajax is going away anytime soon ;)
>
> On 12/1/05, Konstantin Ignatyev
> <kg...@yahoo.com> wrote:
> >
> > I think you and many AJAX fans need a cold shower
> :)
> >
> >
>
http://www.theserverside.com/news/thread.tss?thread_id=37106#187945
> >
> >
> > --- Dan Adams <da...@ifactory.com> wrote:
> >
> > > Excuse my daydreaming for a minute here. I know
> that
> > > same ajax
> > > components exist (and I have not yet personally
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: daydreaming of tapetry and ajax
Posted by Jesse Kuhnert <jk...@gmail.com>.
http://www.w3.org/2006/webapi/
I don't think ajax is going away anytime soon ;)
On 12/1/05, Konstantin Ignatyev <kg...@yahoo.com> wrote:
>
> I think you and many AJAX fans need a cold shower :)
>
> http://www.theserverside.com/news/thread.tss?thread_id=37106#187945
>
>
> --- Dan Adams <da...@ifactory.com> wrote:
>
> > Excuse my daydreaming for a minute here. I know that
> > same ajax
> > components exist (and I have not yet personally
> > gotten into them so
> > forgive me) but what I'm thinking that it might be
> > cool to have a way to
> > easily develop full ajax interfaces rather than just
> > using a few ajax
> > components within pages in a normal request/response
> > type cycle. Are we
> > on our way to this already? I think think it would
> > be SO cool if
> > tapestry could be the first framework to really
> > offer a way of easily
> > developing full ajax apps in the way that it enables
> > easy development
> > now. I mean, more and more you see apps popping up
> > that are ajax based
> > and there are a few javascript libraries out there
> > for doing ajax stuff
> > easier but even so I don't think that this means
> > ajax app development is
> > by no means 'easy'. Am I the only one or would it
> > not be super cool to
> > be able to use tapestry to develop ajax apps that
> > are almost like normal
> > gui apps for the web? Is this something that could
> > be accomplished with
> > an additional library or is it so much of a change
> > that it warrants a
> > new framework?
> >
> > --
> > Dan Adams
> > Software Engineer
> > Interactive Factory
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
>
>
> Konstantin Ignatyev
>
>
>
>
> PS: If this is a typical day on planet earth, humans will add fifteen
> million tons of carbon to the atmosphere, destroy 115 square miles of
> tropical rainforest, create seventy-two miles of desert, eliminate between
> forty to one hundred species, erode seventy-one million tons of topsoil, add
> 2,700 tons of CFCs to the stratosphere, and increase their population by
> 263,000
>
> Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs
> a Strategy for Reforming Universities and Public Schools. New York: State
> University of New York Press, 1997: (4) (5) (p.206)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: daydreaming of tapetry and ajax
Posted by Dan Adams <da...@ifactory.com>.
well, i'm not expecting ajax to take over the world or replace the
normal webapp any time soon. however, i think that there are many
situations where ajax could be a great fit and i'm excited by the fact
that tapestry is posed to be one of the first frameworks to enable
easy(er) ajax app development. in my own work i can think of a number of
examples where ajax would be a terrible choice and i can also think of a
number of others where ajax would not only be a good solution but would
blow the clients socks off. for instance, an ajax-based content
management system could be *very* cool. we've already done some ajax
here but only on the individual component scale.
On Thu, 2005-12-01 at 14:41 -0500, Jesse Kuhnert wrote:
> I'm sorry Konstantin..I should have been more clear about my
> intentions..They are only to make all of these things easier to use in
> tapestry, but on an optional basis. Ie it won't be on by default and will be
> a completely optional choice that people make depending on their own needs.
>
> jesse
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: daydreaming of tapetry and ajax
Posted by Jesse Kuhnert <jk...@gmail.com>.
I'm sorry Konstantin..I should have been more clear about my
intentions..They are only to make all of these things easier to use in
tapestry, but on an optional basis. Ie it won't be on by default and will be
a completely optional choice that people make depending on their own needs.
jesse
On 12/1/05, Jesse Kuhnert <jk...@gmail.com> wrote:
>
> Forgot about this guy, the w3 is moving towards it, but this is what
> forced their hand more or less I think.
>
> http://whatwg.org/specs/web-apps/current-work/
>
> jesse
> On 12/1/05, Konstantin Ignatyev <kg...@yahoo.com> wrote:
> >
> > I think you and many AJAX fans need a cold shower :)
> >
> > http://www.theserverside.com/news/thread.tss?thread_id=37106#187945
> >
> >
> > --- Dan Adams <da...@ifactory.com> wrote:
> >
> > > Excuse my daydreaming for a minute here. I know that
> > > same ajax
> > > components exist (and I have not yet personally
> > > gotten into them so
> > > forgive me) but what I'm thinking that it might be
> > > cool to have a way to
> > > easily develop full ajax interfaces rather than just
> > > using a few ajax
> > > components within pages in a normal request/response
> > > type cycle. Are we
> > > on our way to this already? I think think it would
> > > be SO cool if
> > > tapestry could be the first framework to really
> > > offer a way of easily
> > > developing full ajax apps in the way that it enables
> > > easy development
> > > now. I mean, more and more you see apps popping up
> > > that are ajax based
> > > and there are a few javascript libraries out there
> > > for doing ajax stuff
> > > easier but even so I don't think that this means
> > > ajax app development is
> > > by no means 'easy'. Am I the only one or would it
> > > not be super cool to
> > > be able to use tapestry to develop ajax apps that
> > > are almost like normal
> > > gui apps for the web? Is this something that could
> > > be accomplished with
> > > an additional library or is it so much of a change
> > > that it warrants a
> > > new framework?
> > >
> > > --
> > > Dan Adams
> > > Software Engineer
> > > Interactive Factory
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > tapestry-user-help@jakarta.apache.org
> > >
> > >
> >
> >
> > Konstantin Ignatyev
> >
> >
> >
> >
> > PS: If this is a typical day on planet earth, humans will add fifteen
> > million tons of carbon to the atmosphere, destroy 115 square miles of
> > tropical rainforest, create seventy-two miles of desert, eliminate between
> > forty to one hundred species, erode seventy-one million tons of topsoil, add
> > 2,700 tons of CFCs to the stratosphere, and increase their population by
> > 263,000
> >
> > Bowers, C.A. The Culture of Denial: Why the Environmental Movement
> > Needs a Strategy for Reforming Universities and Public Schools. New
> > York: State University of New York Press, 1997: (4) (5) (p.206)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
Re: daydreaming of tapetry and ajax
Posted by Jesse Kuhnert <jk...@gmail.com>.
Forgot about this guy, the w3 is moving towards it, but this is what forced
their hand more or less I think.
http://whatwg.org/specs/web-apps/current-work/
jesse
On 12/1/05, Konstantin Ignatyev <kg...@yahoo.com> wrote:
>
> I think you and many AJAX fans need a cold shower :)
>
> http://www.theserverside.com/news/thread.tss?thread_id=37106#187945
>
>
> --- Dan Adams <da...@ifactory.com> wrote:
>
> > Excuse my daydreaming for a minute here. I know that
> > same ajax
> > components exist (and I have not yet personally
> > gotten into them so
> > forgive me) but what I'm thinking that it might be
> > cool to have a way to
> > easily develop full ajax interfaces rather than just
> > using a few ajax
> > components within pages in a normal request/response
> > type cycle. Are we
> > on our way to this already? I think think it would
> > be SO cool if
> > tapestry could be the first framework to really
> > offer a way of easily
> > developing full ajax apps in the way that it enables
> > easy development
> > now. I mean, more and more you see apps popping up
> > that are ajax based
> > and there are a few javascript libraries out there
> > for doing ajax stuff
> > easier but even so I don't think that this means
> > ajax app development is
> > by no means 'easy'. Am I the only one or would it
> > not be super cool to
> > be able to use tapestry to develop ajax apps that
> > are almost like normal
> > gui apps for the web? Is this something that could
> > be accomplished with
> > an additional library or is it so much of a change
> > that it warrants a
> > new framework?
> >
> > --
> > Dan Adams
> > Software Engineer
> > Interactive Factory
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
>
>
> Konstantin Ignatyev
>
>
>
>
> PS: If this is a typical day on planet earth, humans will add fifteen
> million tons of carbon to the atmosphere, destroy 115 square miles of
> tropical rainforest, create seventy-two miles of desert, eliminate between
> forty to one hundred species, erode seventy-one million tons of topsoil, add
> 2,700 tons of CFCs to the stratosphere, and increase their population by
> 263,000
>
> Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs
> a Strategy for Reforming Universities and Public Schools. New York: State
> University of New York Press, 1997: (4) (5) (p.206)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: daydreaming of tapetry and ajax
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
I think you and many AJAX fans need a cold shower :)
http://www.theserverside.com/news/thread.tss?thread_id=37106#187945
--- Dan Adams <da...@ifactory.com> wrote:
> Excuse my daydreaming for a minute here. I know that
> same ajax
> components exist (and I have not yet personally
> gotten into them so
> forgive me) but what I'm thinking that it might be
> cool to have a way to
> easily develop full ajax interfaces rather than just
> using a few ajax
> components within pages in a normal request/response
> type cycle. Are we
> on our way to this already? I think think it would
> be SO cool if
> tapestry could be the first framework to really
> offer a way of easily
> developing full ajax apps in the way that it enables
> easy development
> now. I mean, more and more you see apps popping up
> that are ajax based
> and there are a few javascript libraries out there
> for doing ajax stuff
> easier but even so I don't think that this means
> ajax app development is
> by no means 'easy'. Am I the only one or would it
> not be super cool to
> be able to use tapestry to develop ajax apps that
> are almost like normal
> gui apps for the web? Is this something that could
> be accomplished with
> an additional library or is it so much of a change
> that it warrants a
> new framework?
>
> --
> Dan Adams
> Software Engineer
> Interactive Factory
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
Konstantin Ignatyev
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org