You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2012/10/25 23:28:21 UTC
Abstract layer or jquery all the way?
As much fun as I've been having with the JavaScript abstraction layer
... is it really needed?
Could we please 90% (99% ?) of our users by providing jQuery out of
the box, and coding the Tapestry support directly against it?
How many people will care about the SPI? How many will stay on
Prototype when jQuery is an option? How many will be desperate top
use just MooTools. or just YUI, or just Dojo, and can't handle having
anything else?
Just want to explore all the options.
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 25 Oct 2012 23:41:02 -0200, Bob Harner <bo...@gmail.com> wrote:
> A big +1 for the abstraction layer. Sure, everybody is using jQuery
> now, but what in about a year or two? There is always a new "hot"
> thing around the corner, especially in JavaScript land.
That's exactly what I was thinking. Prototype was the right and popular
choice when Tapestry 5 was at its alpha versions. Now it's jQuery. Maybe,
in the not so distant future, browsers themselves will provide that in a
mostly consistent manner (W3C Selectors API for DOM node search
http://www.w3.org/TR/selectors-api/, etc) so JS frameworks aren't needed
as they are today.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Bob Harner <bo...@gmail.com>.
A big +1 for the abstraction layer. Sure, everybody is using jQuery
now, but what in about a year or two? There is always a new "hot"
thing around the corner, especially in JavaScript land.
On Thu, Oct 25, 2012 at 8:07 PM, Thiago H de Paula Figueiredo
<th...@gmail.com> wrote:
> +1 for SPI. I think it wouldn't end up large, covering mostly DOM node
> searching (Prototype's $$() and jQuery's $()), list processing (foreach) and
> event binding. Howard, you're already working on the JavaScript rewriting,
> so you're the right person to tell me if I'm right or not. :)
>
>
> On Thu, 25 Oct 2012 19:28:21 -0200, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
>> As much fun as I've been having with the JavaScript abstraction layer
>> ... is it really needed?
>>
>> Could we please 90% (99% ?) of our users by providing jQuery out of
>> the box, and coding the Tapestry support directly against it?
>>
>> How many people will care about the SPI? How many will stay on
>> Prototype when jQuery is an option? How many will be desperate top
>> use just MooTools. or just YUI, or just Dojo, and can't handle having
>> anything else?
>>
>> Just want to explore all the options.
>>
>
>
> --
> Thiago H. de Paula Figueiredo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
+1 for SPI. I think it wouldn't end up large, covering mostly DOM node
searching (Prototype's $$() and jQuery's $()), list processing (foreach)
and event binding. Howard, you're already working on the JavaScript
rewriting, so you're the right person to tell me if I'm right or not. :)
On Thu, 25 Oct 2012 19:28:21 -0200, Howard Lewis Ship <hl...@gmail.com>
wrote:
> As much fun as I've been having with the JavaScript abstraction layer
> ... is it really needed?
>
> Could we please 90% (99% ?) of our users by providing jQuery out of
> the box, and coding the Tapestry support directly against it?
>
> How many people will care about the SPI? How many will stay on
> Prototype when jQuery is an option? How many will be desperate top
> use just MooTools. or just YUI, or just Dojo, and can't handle having
> anything else?
>
> Just want to explore all the options.
>
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Thu, Oct 25, 2012 at 3:06 PM, Denis Stepanov
<de...@gmail.com> wrote:
> I'm differently against SPI and all that javascript abstraction.
>
> In my opinion, if you write javascript clean:
>
> use coffeescript
That is irrelevant, but I prefer coding in CoffeeScript.
> separate different functionality into own files
I thought you didn't like that? Yes, I'm doing many small modules.
> no .ajax, console. wrappers use provided framework functionality
I don't follow you here; the wrappers are there for a purpose, which
is that the functionality does not always exist; if every bit of code
that wanted to use the console was written for all the possibilities
across browsers, it would be a disaster.
Likewise, the Ajax abstraction are in two layers; 1 layer is the
foundation framework (e.g., Prototype or jQuery). The other is extra
reporting, and automatic handling of the partial page render response
before giving control back to the success handler.
> if you need to acknowledge an error throw an exception
This will tend to make things very brittle I think, especially for
apps that are hitting rough edges upgrading from 5.3 to 5.4. Maybe
I'm falling into the old trap, though; I'll think about it.
> eliminate dependencies by using events as the API between them
This is certainly the case, and the events are well defined because
there is a namespace just to define the events.
> …
>
> final result is that you have pretty manageable javascript and if you don't like the framework you can easily rewrite it or just copy and extend it, in big projects it is probably needed anyway.
That is certainly the path we're on, in the 5.4-js-rewrite branch.
>
> I'm for as less javascript as possible solution and jQuery.
I think the amount of JavaScript in 5.4, will be much smaller than
5.3, and accomplish a lot more.
>
> Denis
>
> 25. 10. 2012 v 23:28, Howard Lewis Ship <hl...@gmail.com>:
>
>> As much fun as I've been having with the JavaScript abstraction layer
>> ... is it really needed?
>>
>> Could we please 90% (99% ?) of our users by providing jQuery out of
>> the box, and coding the Tapestry support directly against it?
>>
>> How many people will care about the SPI? How many will stay on
>> Prototype when jQuery is an option? How many will be desperate top
>> use just MooTools. or just YUI, or just Dojo, and can't handle having
>> anything else?
>>
>> Just want to explore all the options.
>>
>> --
>> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Denis Stepanov <de...@gmail.com>.
I'm differently against SPI and all that javascript abstraction.
In my opinion, if you write javascript clean:
use coffeescript
separate different functionality into own files
no .ajax, console. wrappers use provided framework functionality
if you need to acknowledge an error throw an exception
eliminate dependencies by using events as the API between them
…
final result is that you have pretty manageable javascript and if you don't like the framework you can easily rewrite it or just copy and extend it, in big projects it is probably needed anyway.
I'm for as less javascript as possible solution and jQuery.
Denis
25. 10. 2012 v 23:28, Howard Lewis Ship <hl...@gmail.com>:
> As much fun as I've been having with the JavaScript abstraction layer
> ... is it really needed?
>
> Could we please 90% (99% ?) of our users by providing jQuery out of
> the box, and coding the Tapestry support directly against it?
>
> How many people will care about the SPI? How many will stay on
> Prototype when jQuery is an option? How many will be desperate top
> use just MooTools. or just YUI, or just Dojo, and can't handle having
> anything else?
>
> Just want to explore all the options.
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Denis Stepanov <de...@gmail.com>.
> I thought you didn't like that? Yes, I'm doing many small modules.
Separating javascript doesn't necessary mean modules, every file contributing into the main context e.g. jQuery https://github.com/jquery/jquery/tree/master/src
If there will be server side modules in the future version you can simply replace one file/module e.g. core/console, it is why I don't think there is necessary to use requireJS at all, if it is done correctly you should be able to replace some of the functionality from the client side.
https://github.com/apache/tapestry-5/tree/5.4-js-rewrite/tapestry-core/src/main/coffeescript/META-INF/modules/core
It looks like you are creating new javascript framework which would be an abstraction between jquery, prototype or anything else, honestly I don't think it is a way to go.
Denis
Oct 26, 2012 v 8:34 AM, Ulrich Stärk <ul...@spielviel.de>:
> We don't have to reinvent the wheel for that one. We might simply look around and see how other
> frameworks are solving this. If we don't like what we see we can still do it differently but what
> works for others might also work for us.
>
> Uli
>
> On 25.10.2012 23:28, Howard Lewis Ship wrote:
>> As much fun as I've been having with the JavaScript abstraction layer
>> ... is it really needed?
>>
>> Could we please 90% (99% ?) of our users by providing jQuery out of
>> the box, and coding the Tapestry support directly against it?
>>
>> How many people will care about the SPI? How many will stay on
>> Prototype when jQuery is an option? How many will be desperate top
>> use just MooTools. or just YUI, or just Dojo, and can't handle having
>> anything else?
>>
>> Just want to explore all the options.
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
Denis
Re: Abstract layer or jquery all the way?
Posted by Ulrich Stärk <ul...@spielviel.de>.
We don't have to reinvent the wheel for that one. We might simply look around and see how other
frameworks are solving this. If we don't like what we see we can still do it differently but what
works for others might also work for us.
Uli
On 25.10.2012 23:28, Howard Lewis Ship wrote:
> As much fun as I've been having with the JavaScript abstraction layer
> ... is it really needed?
>
> Could we please 90% (99% ?) of our users by providing jQuery out of
> the box, and coding the Tapestry support directly against it?
>
> How many people will care about the SPI? How many will stay on
> Prototype when jQuery is an option? How many will be desperate top
> use just MooTools. or just YUI, or just Dojo, and can't handle having
> anything else?
>
> Just want to explore all the options.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Massimo Lusetti <ml...@gmail.com>.
On Mon, Oct 29, 2012 at 12:03 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> validation, and so forth. I expect to merge back into master pretty
> soon.
Great news.
Cheers
--
Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <du...@gmail.com> 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 <tr...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Dusko Jovanovski <du...@gmail.com>.
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 <tr...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: Abstract layer or jquery all the way?
Posted by trsvax <tr...@gmail.com>.
> - 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 26 Oct 2012 23:00:41 -0200, Geoff Callender
<ge...@gmail.com> wrote:
> I can't find a definition of SPI in this mailing list. Is it:
Yep, it doesn't seem to me that everyone talking about SPIs and
abstraction layers have a different definition for them. Howard, as you're
the one who started this discussion, how would you define them?
> - Service Provider Interface?
> - Script Programming Interface?
> - Single Page Interface?
>
> I'm guessing it's #2.
I guess it's #1, but #2 is maybe the same thing. :)
> If so, then it sounds like an excellent idea, and I'm guessing it would
> have to be written in raw, vanilla javascript (the lowest common
> denominator)
I agree with this part.
> so that everyone can call it from their preferred flavour of javascript.
But not with this one. People (a.k.a. not Tapestry itself) would use their
preferred JavaScript frameworks directly, while Tapestry itself would use
the SPI in order to not use Prototype or jQuery directly. This way, the
Tapestry JavaScript code would be 100% JS framework-agnostic.
> If I'm on track now, could someone post some examples/proposals of
> interface code, eg. the interface for Zone handling; so we can see what
> we're talking about?
+1.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Geoff Callender <ge...@gmail.com>.
I can't find a definition of SPI in this mailing list. Is it:
- Service Provider Interface?
- Script Programming Interface?
- Single Page Interface?
I'm guessing it's #2. If so, then it sounds like an excellent idea, and I'm guessing it would have to be written in raw, vanilla javascript (the lowest common denominator) so that everyone can call it from their preferred flavour of javascript.
As for the implementation beneath the SPI, sure, jQuery sounds as good a solution as any, and I see no harm in locking that in.
If I'm on track now, could someone post some examples/proposals of interface code, eg. the interface for Zone handling; so we can see what we're talking about?
Cheers,
Geoff
On 27/10/2012, at 3:48 AM, Massimo Lusetti wrote:
> On Fri, Oct 26, 2012 at 4:28 PM, Geoff Callender
> <ge...@gmail.com> wrote:
>
>> I'm a bit lost in all of this. I thought an aim of 5.4 was to make it easy to use widgets from other JavaScript libraries, eg. the huge range of widgets in Ext JS, or any other library that gains traction? Is that still the case?
>>
>
> That's the question Geoff, which I think a lot of people don't
> actually understand.
>
> The whole point here, in the tapestry javascript SPI, is to facilitate
> the ability to plug new components build on your favorite javascript
> library.
>
> There's no way to "abstract" a component behavior to let it be
> functional with all javascript libraries, in that case you should
> (must) write your own javascript component with your preferred
> javascript library, the SPI "abstraction" is there to facilitate the
> communication with the tapestry5 framework.
>
> Cheers
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Massimo Lusetti <ml...@gmail.com>.
On Fri, Oct 26, 2012 at 4:28 PM, Geoff Callender
<ge...@gmail.com> wrote:
> I'm a bit lost in all of this. I thought an aim of 5.4 was to make it easy to use widgets from other JavaScript libraries, eg. the huge range of widgets in Ext JS, or any other library that gains traction? Is that still the case?
>
That's the question Geoff, which I think a lot of people don't
actually understand.
The whole point here, in the tapestry javascript SPI, is to facilitate
the ability to plug new components build on your favorite javascript
library.
There's no way to "abstract" a component behavior to let it be
functional with all javascript libraries, in that case you should
(must) write your own javascript component with your preferred
javascript library, the SPI "abstraction" is there to facilitate the
communication with the tapestry5 framework.
Cheers
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 26 Oct 2012 12:53:41 -0200, trsvax <tr...@gmail.com> wrote:
> I hope this is the goal also and I guess my question is what does make it
> easy mean? If you wanted to use Ext JS components what would you want
> would you want an abstraction layer to do?
I don't think so. You could just use ExtJS or anything else the same way
you would without Tapestry. As I've said earlier, the abstraction layer
would specifically be for Tapestry internal use (so, for example, it would
be easy and quick to have the Zone JavaScript written in Prototype and in
jQuery) and any Tapestry application could use any framework directly. I
really think you're thinking the abstraction layer is something quite
different from what it will be.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by trsvax <tr...@gmail.com>.
I hope this is the goal also and I guess my question is what does make it
easy mean? If you wanted to use Ext JS components what would you want would
you want an abstraction layer to do? I would just grab the compressed
Javascript, put it on a server and write some Java component interfaces. I
would not worry if it was compatible with jQuery components or not. It would
be nice if someone created a module and shared it but does anyone really
expect to one day decide I'm switching from jQuery to Ext JS, change a Maven
dependency and have everything just work?
I think it was Scott McNealy said 'All the wood behind one arrowhead'. He
just picked the wrong arrowhead.
Barry
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Abstract-layer-or-jquery-all-the-way-tp5717250p5717302.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Geoff Callender <ge...@gmail.com>.
I'm a bit lost in all of this. I thought an aim of 5.4 was to make it easy to use widgets from other JavaScript libraries, eg. the huge range of widgets in Ext JS, or any other library that gains traction? Is that still the case?
Geoff
On 27/10/2012, at 12:11 AM, Thiago H de Paula Figueiredo wrote:
> On Fri, 26 Oct 2012 10:47:35 -0200, trsvax <tr...@gmail.com> wrote:
>
>> 1. With things like mod_pagespeed now appearing it's not clear to me the
>> work of optimizing page load times belongs in the framework. Since there is a common solution development time might be better spent elsewhere.
>
> That's an Apache module and many people don't use it.
>
>> 2. Abstraction layers require a lot of work and in most cases never really solve the problem. If developers are going to provide modules that have
>> Javascript enabled components how would they be written? If they only use
>> the abstraction layer then Tapestry will end up creating a complete
>> Javascript framework.
>
> Nope, I don't think this is going to happen (creating a complete JavaScript framework). Otherwise, it wouldn't be an abstraction layer. The Java equivalent would be creating interfaces and have a jQuery implementation of it, also a Prototype one.
>
>> 3. If someone wants to include an existing jQuery component they will need the jQuery library anyway and if Tapestry really is going to head down the Bootstrap path the Bootstrap components are jQuery components.
>
> That's the Bob Harner's point. What you said was valid for Prototype years ago, is valid now, but it may not be valid in the next years. Again, we would have people complaining that Tapestry uses a JavaScript framework that isn't the best anymore.
>
>> I have a large site that is not jQuery and for it backward compatibility is very important. What I would like to see is the Javascript part become a
>> module and you just pick the one you want and go.
>
> The abstraction layer would be needed for these modules to be written without rewriting everything in jQuery and in Prototype.
>
>> The two javascript modules
>> I'd like to see are the old legacy Prototype one and a Bootstrap-jQuery one. I don't see any benefit to an abstraction layer on the jQuery side. Many
>> people know jQuery and it's well documented. Why introduce a layer that just makes things more difficult?
>
> The abstraction layer is intended to be used mostly by Tapestry itself, probably component libraries too. Your code using jQuery would work exactly the same. Of course, people could use the abstraction layer too, but that's up to them.
>
> --
> Thiago H. de Paula Figueiredo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 26 Oct 2012 12:32:16 -0200, trsvax <tr...@gmail.com> wrote:
>> Nope, I don't think this is going to happen (creating a complete
>> JavaScript framework). Otherwise, it wouldn't be an abstraction layer.
>> The
>> Java equivalent would be creating interfaces and have a jQuery
>> implementation of it, also a Prototype one.
>
> I don't think it's going to happen (or should happen) either which is
> way I don't see any benefit in trying.
I don' think so, but something like that already happened once, so it can
happen again.
> I do think this is a valid point but with Prototype there was still an
> abstraction layer. It was not easy to pickup a Prototype component and
> just use it. jQuery is different in that respect. It's possible to easily
> integrate existing widgets with no Javascript and virtually no Java. In
> fact> with some framework support I certain it could be done by just
> dropping a
> javascript file into the resources.widgets directory.
I think you're confusing Prototype and Scriptaculous here. The abstraction
layer, as far as I can see, wouldn't deal with GUI stuff (that's
Scriptaculous), just DOM handling and events (that's Prototype).
> The question is would it be better to have excellent support for the
> currently popular framework or mediocre support for none of them. I don't
> think this is really a backward compatibility issue because as you say
> the abstraction layer will not be complete enough to really shield you
> from the underlying Javascript framework anyway.
The abstraction layer, again, is for Tapestry itself, not for us when
we're creating websites with it.
> I do think it's true that people will complain no matter what. I know I
> will :)
Agreed! :)
>>> I have a large site that is not jQuery and for it backward
>>> compatibility
>>> is very important. What I would like to see is the Javascript part
>>> become a
>>> module and you just pick the one you want and go.
>>
>> The abstraction layer would be needed for these modules to be written
>> without rewriting everything in jQuery and in Prototype.
>
> I don't see how a Javascript abstraction layer helps you here because I
> think the correct abstraction point is the Java component. Let's say you
> want a Calendar component. The jQuery and Prototype calendars are
> completely
> different but they can appear the same at the Tapestry component level.
> What
> does a Javascript abstraction layer bring to the table? You will still
> need
> to create two different components.
Yes, but the resulting code will be shorter.
> I'm likely to continue using Tapestry whichever way it goes but I will
> say if my existing 5.3 site does not work in 5.4 because of Javascript
> abstraction layer changes it's going to be a lot of work for me to get to
> 5.4.
Again, that's not going to happen.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by trsvax <tr...@gmail.com>.
>On Fri, 26 Oct 2012 10:47:35 -0200, trsvax <[hidden email]> wrote:
>
>> 1. With things like mod_pagespeed now appearing it's not clear to me the
>> work of optimizing page load times belongs in the framework. Since there
>> is a common solution development time might be better spent elsewhere.
>
>That's an Apache module and many people don't use it.
I don't use the Apache module either, but I think the current script
combining compression code is more trouble than it's worth because it does
not solve any problems very well. For small sites it's easier just to have
one file already compressed. For high volume sites I would use a CDN and the
framework just gets in the way. In fact these days small sites should
probably just use the Google CDN.
https://developers.google.com/speed/libraries/devguide
>
>> 2. Abstraction layers require a lot of work and in most cases never
>> really solve the problem. If developers are going to provide modules
>> that have
>> Javascript enabled components how would they be written? If they only use
>> the abstraction layer then Tapestry will end up creating a complete
>> Javascript framework.
>
>Nope, I don't think this is going to happen (creating a complete
>JavaScript framework). Otherwise, it wouldn't be an abstraction layer. The
>Java equivalent would be creating interfaces and have a jQuery
>implementation of it, also a Prototype one.
I don't think it's going to happen (or should happen) either which is way I
don't see any benefit in trying.
>
>> 3. If someone wants to include an existing jQuery component they will
>> need the jQuery library anyway and if Tapestry really is going to head
>> down the Bootstrap path the Bootstrap components are jQuery components.
>
>That's the Bob Harner's point. What you said was valid for Prototype years
>ago, is valid now, but it may not be valid in the next years. Again, we
>would have people complaining that Tapestry uses a JavaScript framework
>that isn't the best anymore.
I do think this is a valid point but with Prototype there was still an
abstraction layer. It was not easy to pickup a Prototype component and just
use it. jQuery is different in that respect. It's possible to easily
integrate existing widgets with no Javascript and virtually no Java. In fact
with some framework support I certain it could be done by just dropping a
javascript file into the resources.widgets directory.
The question is would it be better to have excellent support for the
currently popular framework or mediocre support for none of them. I don't
think this is really a backward compatibility issue because as you say the
abstraction layer will not be complete enough to really shield you from the
underlying Javascript framework anyway.
I do think it's true that people will complain no matter what. I know I will
:)
>
>> I have a large site that is not jQuery and for it backward compatibility
>> is very important. What I would like to see is the Javascript part
>> become a
>> module and you just pick the one you want and go.
>
>The abstraction layer would be needed for these modules to be written
>without rewriting everything in jQuery and in Prototype.
I don't see how a Javascript abstraction layer helps you here because I
think the correct abstraction point is the Java component. Let's say you
want a Calendar component. The jQuery and Prototype calendars are completely
different but they can appear the same at the Tapestry component level. What
does a Javascript abstraction layer bring to the table? You will still need
to create two different components.
>
>> The two javascript modules
>> I'd like to see are the old legacy Prototype one and a Bootstrap-jQuery
>> one. I don't see any benefit to an abstraction layer on the jQuery side.
>> Many
>> people know jQuery and it's well documented. Why introduce a layer that
>> just makes things more difficult?
>
>The abstraction layer is intended to be used mostly by Tapestry itself,
>probably component libraries too. Your code using jQuery would work
>exactly the same. Of course, people could use the abstraction layer too,
>but that's up to them.
I think you are correct here, the abstraction layer would be used by the
framework developers and not so much by the end user. In fact I think it's
actually detrimental to the module builder. For example I'm not going to
create Prototype equivalents to the jQuery Bootstrap components. It's not
worth my time.
I suspect I'm not alone in that thinking so my question is how many
Javascript frameworks will the base Tapestry framework support? If it's the
legacy Prototype one and jQuery then I don't see any benefit to the
framework either and I would put this in the premature optimization
category. I also don't think it's possible to build an abstraction layer
that encompasses some of the existing current possibilities such as GWT. In
fact I know other existing frameworks present their own challenges. For
example the Facebook API has it's own async script loading mechanism. The
current Tapestry abstraction layer does not work with it. Will the proposed
one support it? If the proposed abstraction layer cannot support popular
existing frameworks it seems unlikely it will support future ones.
I'm likely to continue using Tapestry whichever way it goes but I will say
if my existing 5.3 site does not work in 5.4 because of Javascript
abstraction layer changes it's going to be a lot of work for me to get to
5.4. Given that choice I'd rather just convert to jQuery than a different
abstraction layer.
>
>--
>Thiago H. de Paula Figueiredo
Thanks for your comments. They are insightful as always.
Barry
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Abstract-layer-or-jquery-all-the-way-tp5717250p5717299.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 26 Oct 2012 10:47:35 -0200, trsvax <tr...@gmail.com> wrote:
> 1. With things like mod_pagespeed now appearing it's not clear to me the
> work of optimizing page load times belongs in the framework. Since there
> is a common solution development time might be better spent elsewhere.
That's an Apache module and many people don't use it.
> 2. Abstraction layers require a lot of work and in most cases never
> really solve the problem. If developers are going to provide modules
> that have
> Javascript enabled components how would they be written? If they only use
> the abstraction layer then Tapestry will end up creating a complete
> Javascript framework.
Nope, I don't think this is going to happen (creating a complete
JavaScript framework). Otherwise, it wouldn't be an abstraction layer. The
Java equivalent would be creating interfaces and have a jQuery
implementation of it, also a Prototype one.
> 3. If someone wants to include an existing jQuery component they will
> need the jQuery library anyway and if Tapestry really is going to head
> down the Bootstrap path the Bootstrap components are jQuery components.
That's the Bob Harner's point. What you said was valid for Prototype years
ago, is valid now, but it may not be valid in the next years. Again, we
would have people complaining that Tapestry uses a JavaScript framework
that isn't the best anymore.
> I have a large site that is not jQuery and for it backward compatibility
> is very important. What I would like to see is the Javascript part
> become a
> module and you just pick the one you want and go.
The abstraction layer would be needed for these modules to be written
without rewriting everything in jQuery and in Prototype.
> The two javascript modules
> I'd like to see are the old legacy Prototype one and a Bootstrap-jQuery
> one. I don't see any benefit to an abstraction layer on the jQuery side.
> Many
> people know jQuery and it's well documented. Why introduce a layer that
> just makes things more difficult?
The abstraction layer is intended to be used mostly by Tapestry itself,
probably component libraries too. Your code using jQuery would work
exactly the same. Of course, people could use the abstraction layer too,
but that's up to them.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Abstract layer or jquery all the way?
Posted by trsvax <tr...@gmail.com>.
I'm glad you asked this question. Here are my thoughts.
I was never really a big Javascript fan and I used Tapestry for many years
without writing a single line of Javascript. As time passed it became
obvious that this Javascript thing was here to stay and the current world
used jQuery so I started using the Tapestry5-jQuery library and never looked
back. JQuery has documentation, plenty of widgets and since widgets have a
common interface the are easily integrated with only a few lines of Java.
Lastly Bootstrap is using jQuery.
Many people have pointed out the drawbacks of tying the framework to a
particular Javascript framework and the choice of Prototype has made some of
these fears come true but there are also benefits to picking one.
1. With things like mod_pagespeed now appearing it's not clear to me the
work of optimizing page load times belongs in the framework. Since there is
a common solution development time might be better spent elsewhere.
2. Abstraction layers require a lot of work and in most cases never really
solve the problem. If developers are going to provide modules that have
Javascript enabled components how would they be written? If they only use
the abstraction layer then Tapestry will end up creating a complete
Javascript framework.
3. If someone wants to include an existing jQuery component they will need
the jQuery library anyway and if Tapestry really is going to head down the
Bootstrap path the Bootstrap components are jQuery components.
I have a large site that is not jQuery and for it backward compatibility is
very important. What I would like to see is the Javascript part become a
module and you just pick the one you want and go. The two javascript modules
I'd like to see are the old legacy Prototype one and a Bootstrap-jQuery one.
I don't see any benefit to an abstraction layer on the jQuery side. Many
people know jQuery and it's well documented. Why introduce a layer that just
makes things more difficult?
The other feature I'd like to see is a component-path configuration that
would allow all components to be used without a prefix just like the Unix
shell path. This would make it easier to override existing components and
use multiple component libraries.
Creating the Tapestry-Bootstrap module gave me a better appreciation of how
good Tapestry is. I was able to plug in a whole new gui front end that was
backward compatible with existing Java code. That said there are some rough
edges and inconsistencies I'd like to see fixed.
I've also used GWT with Tapestry and if you really want to abstract away the
Javascript layer it's the way to go. With GWT it's possible to create an
entire site using only Java and you can debug both the client and server
side in the same debug session. It's a very nice environment but I think a
bit too far out there to become mainstream. The reason I bring it up is I
think it would make a nice Javascript Module but any Javascript abstraction
layer would be useless to it.
Lastly from a practical standpoint I think developers are either going to
build site using only Tapestry components perhaps with a bit a Javascript or
pick their favorite Javascript framework and go from there. I think Tapestry
should be able to provide backward compatibility for either of those
options. I don't think it can deliver on a promise of being Javascript
framework independent and by that I mean you can plug in any Javascript
framework and the existing components just magically adapt to it.
Finally there is a lot of momentum behind Bootstrap right now but it also
looks like Twitter is letting it go. At this point it's difficult to know
what will happen. My feeling is Tapestry with jQuery/Bootstrap would easily
be the best web development framework out there. It would have a great
foundation for building sites fast and provide a vast library of easily
integrated Javascript components.
Thanks
Barry
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Abstract-layer-or-jquery-all-the-way-tp5717250p5717285.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org