tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard Lewis Ship" <hls...@gmail.com>
Subject Re: RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Date Thu, 04 Oct 2007 01:42:12 GMT
I think we may want to cut a branch (or two) to experiment on this.

Basic operations:

- validate field (on submit? on loss of focus?)
- declarative validation ala T4.1? aka the json blob
- hide element (instant)
- fade element (animated)
- reveal element (instant)
- fadeIn element (animated)
- page loaded initialization
- bind a function as an event handler of an element
- basic Ajax support, including partial updates (more json)

Basically, enough to support validation, Palette, some kind of
calendar/date input, etc.

I think we're falling towards a strategy pattern here.

I'd like things to just work to a significant degree.

Configuration would determine the flavor ("jquery", "dojo",
"prototype", "minimal", etc.).

This configuration would do two things:
- inject the correct set of libraries (as prototype/scriptaculous is done today)
- Inject the correct adapter library (i.e., tapestry-jquery.js,
tapestry-dojo.js, etc.)

The different adapters would have the same functions, defined in terms
of the flavor.

Flavor would be configured on a per-application basis.  Maybe ... or
it could be determined on the fly during the render which would allow
us to identify impossible configurations (as in jquery vs. prototype,

I really think that the amount of Ajax rolled into the framework will
be relatively simple, and serious Tapestry/Ajax will be a bit more
about a good foundation and cookbook.

I'm concerned about certain dynamics, such as:  if a field is
non-visible on the client it should bypass validation.  How does the
server know it is not visible, so that server validations can be

Forms are just in general tricky, I think we should support just
show/hide within a form, and the addition of new elements to a form
(think: add a new line item to an invoice), but not much trickier than

Jesse and I had discussed coming up with a shopping list of Ajax Use
Cases to be supported.  Let's start there!

On 10/3/07, Ben Sommerville <ben@bulletproof.com.au> wrote:
> No, I wasn't going that far.
> More that the core library would never directly generate
> javascript, but instead call a pluggable interface for the
> required functionality.  The module that implemented that
> interface would then output the required javascript
> I would see those interfaces as "intention" driven rather
> than functional driven.  That is they would be based on
> the task the core is trying to accomplish rather than
> the features/functions of available javascript libraries.
> Its all very fuzzy at the moment & I think it would need
> a bit of trial & error to get right.
> cheers,
> Ben
> > -----Original Message-----
> > From: Julien HENRY [mailto:henryju@yahoo.fr]
> > Sent: Wednesday, 3 October 2007 10:03 PM
> > To: Tapestry development
> > Subject: RE : RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
> >
> > @Ben: Do you think about something like GWT? I mean
> > programming JavaScript in Java.
> >
> > Components (especially AJAX ones) will certainly use
> > various existing JavaScript libraries. I think the
> > main issue is "what about T5 core components?". Should
> > they use a specific library (without preventing
> > additional components for using their own)?
> >
> > Don't know what could be the best solution... sorry.
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org

Howard M. Lewis Ship
Partner and Senior Architect at Feature50

Creator Apache Tapestry and Apache HiveMind

To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

View raw message