One small example from tapestry.js
when looking at this as prototype centric app
it is totaly ok, but from the angle of enabling other libs this approach
is completely unnecessary and easily fixed.
again this is one example (rewriting all may not be as easy)..
this code is called (tapestry.js:551)
Element.addMethods(['INPUT', 'SELECT', 'TEXTAREA'],
...
getFieldEventManager : function(field)
...
searching whole source for tapestry core reveals that this function is only
used in tapestry.js
tapestry.js:588
element.getFieldEventManager().showValidationMessage(message);
the code can easily be rewriten to use
Tapestry.getFieldEventManager(element).showValidationMessage(message);
this removes need for prototype and extending dome nodes for this example
You can argue that other projects might rely on tapestry doing things like
this,
but an compatible version for prototype can be left like this and version
for other libs
with the new approach (the other libs don't like prototype.js anyway). This
can mean
that people with other js libs are fixed to tapestry core only but this I
suppose is ok for many....
Davor Hrg
On Wed, Feb 11, 2009 at 10:14 PM, Davor Hrg <hrgda...@gmail.com> wrote:
> I was even willing to do this wrapper thing almost a year ago,all this is
> from going through tapestry js code last spring....
> some things are just thoughts on what should not be done, and some may be
> comments on tap.js ....
>
> the Tapestry js code is not so complicated,
> and uses only a portion of prototype
>
> there can even be something like prototype slimmed for it to work as well.
>
> the components are not remotely close in complexity to any framework
> even prototype is overkill for tapestry.
>
> It definitely extensively used Function.bind which is a five-liner and
> is similar dojo.hitch, it also uses $ function which is a simple as well
>
> It should avoid prototype specific approach of expecting dom nodes
> prototypes upgraded and fallback to plain old utility functions
>
> why call :
> $("element").hide()
> when you can as well call (not saying code like this exists in tap.js) :
> Tapestry.hide($('elem'));
> and be more portable
>
> Tapestry core just needs to define a set of minimal js utility functions
> and use prototype for bas on how the funcs should work.
>
> example funcs:
> Tapestry.addClassName
> Tapestry.effect.fadeIn - total light version of js might do no fade and
> just display content
> Tapestry.calcPos - absolute pos for element so a floated one can be aligned
> to it
> some subset of jquery like funcs to more easily find nodes (but search
> only)
> no magic calls to change all nodes properties and shit.
>
> if a submit button can not get context why do crazy stuff in js that is not
> necessary
>
> after that adding/using other js frameworks would be no problem for those
> that like them.
>
> unfortunately I lost a bit of interest after some of my patches not making
> in
> the framework for a long time :(:(
>
> I don't mean to bash on T5, and I do hope I make more time for it in
> following moths.
>
> The blame could be on me as well, a year has almost passed since I looked
> into this, and haven't done much since. :(:(
>
> Davor Hrg
>
>
> On Wed, Feb 4, 2009 at 8:17 AM, Peter Stavrinides <
> p.stavrini...@albourne.com> wrote:
>
>> >it would be nice if a component could indicate
>> >that the scripts should be at the top for the entire page
>> Vote for this Jira, which requests exactly that:
>> https://issues.apache.org/jira/browse/TAP5-369
>>
>> Peter
>>
>> ----- Original Message -----
>> From: "Joachim Van der Auwera" <joac...@progs.be>
>> To: "Tapestry users" <users@tapestry.apache.org>
>> Sent: Monday, 2 February, 2009 17:22:06 GMT +02:00 Athens, Beirut,
>> Bucharest, Istanbul
>> Subject: Re: Switch from Prototype to jQuery?
>>
>> I am not so sure.
>>
>> Do all pages/components work the same way if you move the scripts to the
>> top?
>> If that is the case, then it would be nice if a component could indicate
>> that the scripts should be at the top for the entire page.
>> If not, then there is a problem if you want to combine a component which
>> requires scripts at the top with a component which requires scripts at
>> the bottom.
>>
>> Joachim
>>
>> Kevin Menard wrote:
>> > This was an older app that I haven't needed to revisit. At the time,
>> > no such directive existed. If it does, great. Then I guess there
>> > really aren't any problems after all.
>> >
>> >
>>
>>
>> --
>> Joachim Van der Auwera
>> PROGS bvba, progs.be
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>
