Round and round we go ...

The idea of the SPI is that Tapestry's built in components are coded
against the SPI so that we don't have to have multiple foundation
frameworks in play at any one time. In other words, the client-side
will be "prototype flavor" or "jQuery flavor", or (potentially) "ExtJS
flavor" but not any mix.  A mix is bad because of the amount of
bandwidth that may need to be downloaded to the client, and because
having multiple frameworks in play at the same time can have
unintended consequences such as memory leaks or odd behavior.  For
example (from my blog), Prototype adds a hide() method to Element and
jQuery interpets that as an event handler for the "hide" event ...
which is a custom-named event published by Bootstrap when a modal
dialog is being hidden.  Likewise, Prototype and jQuery don't get
along because they both monkey-patch Function.

In any case, I think the intent is primarily that reusable code
libraries, including the built-in "core" libaray, should code to the
SPI whenever possible, and end-user applications have the option to do
so, or can choose to code directly to the foundation framework.

The SPI is, however, explicitly limited, potentially "leaky", and will
almost certainly have some unwanted overhead in terms of object
creation and processing requirements, vs. coding directly to the
foundation framework. If there was a guarantee that, in the near
future, the foundation framework would always be jQuery, then it would
be a very questionable value.  That is possibly, but not definitely
the case ... who can predict the future? Fortunately, the code in the
SPI, and the code making use of the SPI, is relatively small, so a
future decision to embrace *only* jQuery (or *only*
TheAsYetUninventedSuperFramework) would be a finite cost to switch.

The evolving consensus appears to be to stay the course with the SPI
despite those drawbacks; I invite everyone to follow along in the
5.4-js-rewrite branch and see how it is coming out, and make
suggestions. I'm attempting to limit the SPI to the bare minimum
needed to support the built-in functionality for Zone, form input
validation, and so forth. I expect to merge back into master pretty
soon.


On Sat, Oct 27, 2012 at 6:46 AM, Dusko Jovanovski <[email protected]> wrote:
> Just to clarify, SPI definitely stands for Service Provider Interface. Read
> Howard's blog post on the subject:
> http://tapestryjava.blogspot.com/2012/10/zeroing-in-on-tapestry-54.html
>
> +1 for the @ClientEvent proposal
>
> On Sat, Oct 27, 2012 at 2:54 PM, trsvax <[email protected]> wrote:
>
>> > - Service Provider Interface?
>> > - Script Programming Interface?
>> > - Single Page Interface?
>>
>> It does seem a definition would be nice. I would say #1 also because I
>> think
>> the API spills over into the Java side. For example the current javascript
>> deals with initializing the client side of components and there are Java
>> interfaces into that. I'd prefer a switch to the data attribute style
>> initialization and I don't think that would require any Java side support
>> and very little client side support.
>>
>> I would like to see Java interfaces for client events. Perhaps
>>
>> @ClientEvent(event="pageload")
>> Object onPageLoad() {
>> }
>>
>> I think the Javascript part should be moved to it's own module and you pick
>> the one you want. The ones that I'm interested in are
>>
>> 1. Prototype which works likes (is) the current one
>> 2. jQuery
>>
>> The other tricky part not currently mentioned is what does the HTML
>> generated by the components look like? If there is a switch to Bootstrap
>> the
>> HTML needs to change. Also what happens to things like Calendar and and
>> even
>> the other form components. Bootstrap/jQuery have their own mechanism for
>> handling validation. Will Tapestry use the "native" one or roll it's own? I
>> would hope the "native" one.
>>
>> In summary I think the client side support should be a separate module. I
>> can see the need for more than one just like JPA/Hibernate/roll your own.
>>
>> Given that is there a third provided client module and if so what is it?
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://tapestry.1045711.n5.nabble.com/Abstract-layer-or-jquery-all-the-way-tp5717250p5717339.html
>> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to