Re: Wicket and inline JavaScript
AFAIK jQuery does not pollute at all object prototype. Regarding the wicket way of doing ajax, it shouldn't be changed from scratch. Eventually, small improvements and changes can be made. Alex Objelean. Matej Knopp-2 wrote: Hi, I don't think current wicket output is that bad, just look at what some JSF implementation produce :) Seriously, we might consider different approach (the one like you suggest) for 1.5. But I don't think current wicket approach is something that desperately needs to be fixed, though there certainly is room for improvement. As for jquery unobtrusiveness, IMHO anything that pollutes object prototypes in javascript can hardly be considered inobtrusive. -Matej On Thu, May 22, 2008 at 3:16 PM, Ned Collyer [EMAIL PROTECTED] wrote: Hi Edvin, I am an advocate of JQuery :). I even won their icon design contest, and I've been using it for years! I think it should be used in all projects that require effects or cool DOM manipulation. I love the unobtrusive way and xhtml strict! That being said, when it comes to wicket AJAX - just use the wicket ajax and be done with it. No point mucking with something thats already excellent. It works and its easy. Why reimplement that bit - and potentially open up bugs that you need to go debug. For effects and DOM manipulation, you can use JQuery by adding header contributors. It is cleaner.. and in many instances easier to debug. It makes development quick and painless. If it wasn't wicket - id suggest using JQuery for ajax. Edvin Syse wrote: Hi, I have a webdesigner who keeps harassing me with the way Wicket does JavaScript, attaching behaviour to onclick events etc. instead of doing it the jquery way of picking up the components and attaching the events afterwards, thus keeping all the nasty bits away from the actual markup. Ofcourse the code looks a lot cleaner the jquery way, and he tells me that debugging and working with the code is also much easier. Personally I don't know enough about html/javascript to decide what's the better approach, but I just wanted to know if there are any plans to rework this in Wicket, or if the current approach is just as good? -- Edvin -- View this message in context: http://www.nabble.com/Wicket-and-inline-JavaScript-tp17402101p17404025.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Wicket-and-inline-JavaScript-tp17402101p17445575.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket and inline JavaScript
I am currently in a project where we do everything with jQuery in the frontend, simulating Wicket's AJAX input and using its AJAX output. However, I would not advice in doing this until you have a strong grasp of Wicket's form and AJAX handling. Having a good jquery programmer helps too. Regards, Erik. On Thu, May 22, 2008 at 3:16 PM, Ned Collyer [EMAIL PROTECTED] wrote: Hi Edvin, I am an advocate of JQuery :). I even won their icon design contest, and I've been using it for years! I think it should be used in all projects that require effects or cool DOM manipulation. I love the unobtrusive way and xhtml strict! That being said, when it comes to wicket AJAX - just use the wicket ajax and be done with it. No point mucking with something thats already excellent. It works and its easy. Why reimplement that bit - and potentially open up bugs that you need to go debug. For effects and DOM manipulation, you can use JQuery by adding header contributors. It is cleaner.. and in many instances easier to debug. It makes development quick and painless. If it wasn't wicket - id suggest using JQuery for ajax. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket and inline JavaScript
Hi, I don't think current wicket output is that bad, just look at what some JSF implementation produce :) Seriously, we might consider different approach (the one like you suggest) for 1.5. But I don't think current wicket approach is something that desperately needs to be fixed, though there certainly is room for improvement. As for jquery unobtrusiveness, IMHO anything that pollutes object prototypes in javascript can hardly be considered inobtrusive. -Matej On Thu, May 22, 2008 at 3:16 PM, Ned Collyer [EMAIL PROTECTED] wrote: Hi Edvin, I am an advocate of JQuery :). I even won their icon design contest, and I've been using it for years! I think it should be used in all projects that require effects or cool DOM manipulation. I love the unobtrusive way and xhtml strict! That being said, when it comes to wicket AJAX - just use the wicket ajax and be done with it. No point mucking with something thats already excellent. It works and its easy. Why reimplement that bit - and potentially open up bugs that you need to go debug. For effects and DOM manipulation, you can use JQuery by adding header contributors. It is cleaner.. and in many instances easier to debug. It makes development quick and painless. If it wasn't wicket - id suggest using JQuery for ajax. Edvin Syse wrote: Hi, I have a webdesigner who keeps harassing me with the way Wicket does JavaScript, attaching behaviour to onclick events etc. instead of doing it the jquery way of picking up the components and attaching the events afterwards, thus keeping all the nasty bits away from the actual markup. Ofcourse the code looks a lot cleaner the jquery way, and he tells me that debugging and working with the code is also much easier. Personally I don't know enough about html/javascript to decide what's the better approach, but I just wanted to know if there are any plans to rework this in Wicket, or if the current approach is just as good? -- Edvin -- View this message in context: http://www.nabble.com/Wicket-and-inline-JavaScript-tp17402101p17404025.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wicket and inline JavaScript
Hi, I have a webdesigner who keeps harassing me with the way Wicket does JavaScript, attaching behaviour to onclick events etc. instead of doing it the jquery way of picking up the components and attaching the events afterwards, thus keeping all the nasty bits away from the actual markup. Ofcourse the code looks a lot cleaner the jquery way, and he tells me that debugging and working with the code is also much easier. Personally I don't know enough about html/javascript to decide what's the better approach, but I just wanted to know if there are any plans to rework this in Wicket, or if the current approach is just as good? -- Edvin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket and inline JavaScript
Hi Edvin, I am an advocate of JQuery :). I even won their icon design contest, and I've been using it for years! I think it should be used in all projects that require effects or cool DOM manipulation. I love the unobtrusive way and xhtml strict! That being said, when it comes to wicket AJAX - just use the wicket ajax and be done with it. No point mucking with something thats already excellent. It works and its easy. Why reimplement that bit - and potentially open up bugs that you need to go debug. For effects and DOM manipulation, you can use JQuery by adding header contributors. It is cleaner.. and in many instances easier to debug. It makes development quick and painless. If it wasn't wicket - id suggest using JQuery for ajax. Edvin Syse wrote: Hi, I have a webdesigner who keeps harassing me with the way Wicket does JavaScript, attaching behaviour to onclick events etc. instead of doing it the jquery way of picking up the components and attaching the events afterwards, thus keeping all the nasty bits away from the actual markup. Ofcourse the code looks a lot cleaner the jquery way, and he tells me that debugging and working with the code is also much easier. Personally I don't know enough about html/javascript to decide what's the better approach, but I just wanted to know if there are any plans to rework this in Wicket, or if the current approach is just as good? -- Edvin -- View this message in context: http://www.nabble.com/Wicket-and-inline-JavaScript-tp17402101p17404025.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket and inline JavaScript
Hi Ned,
thanks for your reply. I agree with your point of view. Today, however,
we got bitten because the designer wanted to change all buttons by
hiding them with jquery, and adding an anchor right after it in the
dom-tree, so he could style them the way he wanted it (not possible with
buttons he tells me).
You can see his lovely button on this page:
http://sd.tornado.no/domorder/search/query/testdomain
The way he then triggered the submit buttons is with the following
Jquery code:
$('.btn.submit').click(function(){
$(this).prev().click();
});
This works most of the times, but sometimes, when the wicket ajax stuff
includes references to 'this', the approach doesn't work, and wicket
tells me that the ajax request was stopped 'because of precondition'.
That's when he started bitching about the Wicket way of inlining
JavaScript, so I thought I'd be nice to hear some opinions :))
-- Edvin
Ned Collyer skrev:
Hi Edvin,
I am an advocate of JQuery :). I even won their icon design contest, and
I've been using it for years! I think it should be used in all projects
that require effects or cool DOM manipulation.
I love the unobtrusive way and xhtml strict!
That being said, when it comes to wicket AJAX - just use the wicket ajax and
be done with it. No point mucking with something thats already excellent.
It works and its easy. Why reimplement that bit - and potentially open up
bugs that you need to go debug.
For effects and DOM manipulation, you can use JQuery by adding header
contributors. It is cleaner.. and in many instances easier to debug. It
makes development quick and painless.
If it wasn't wicket - id suggest using JQuery for ajax.
Edvin Syse wrote:
Hi,
I have a webdesigner who keeps harassing me with the way Wicket does
JavaScript, attaching behaviour to onclick events etc. instead of doing
it the jquery way of picking up the components and attaching the
events afterwards, thus keeping all the nasty bits away from the actual
markup.
Ofcourse the code looks a lot cleaner the jquery way, and he tells me
that debugging and working with the code is also much easier. Personally
I don't know enough about html/javascript to decide what's the better
approach, but I just wanted to know if there are any plans to rework
this in Wicket, or if the current approach is just as good?
-- Edvin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket and inline JavaScript
I can't give you a fix off the top of my head... that being said..
Your designer should forage into usability.
You can style buttons - in a limited fashion and its not consistent across
browser types - its a PITA! Don't do it!
The last thing we need is buttons that don't look like buttons. The reason
most apps (web and non web) use normal form controls is because users
understand them and are familiar because their OS will look the same. In
the same way links should 99% of the time have a blue underline. Instantly
you know what its behaviour is. Oh this submits a form, Oh this is a link
it will take me to a site
I know there has been some make web 2.0 button tutorial stuff floating
around recently - perhaps they've seen these and want to add some drop
shadows and [EMAIL PROTECTED]
:) but if your design really needs custom form submits to make it
work...rethink the custom form design and make it standard. Form controls
are a solved problem.
In summary - regardless of the technology in use - in my personal view..
from studying this stuff for years custom buttons is a waste of time and
is actually worse for your app from a usability stand point.
Given the right argument I might be swayed in certain circumstances - but
that's the general rule of thumb.
I work very closely with a designer who was initially into making everything
his canvas! Now he understands usability concerns - and also that it
doesn't effect creativity, but actually makes the apps better.
Edvin Syse wrote:
Hi Ned,
thanks for your reply. I agree with your point of view. Today, however,
we got bitten because the designer wanted to change all buttons by
hiding them with jquery, and adding an anchor right after it in the
dom-tree, so he could style them the way he wanted it (not possible with
buttons he tells me).
You can see his lovely button on this page:
http://sd.tornado.no/domorder/search/query/testdomain
The way he then triggered the submit buttons is with the following
Jquery code:
$('.btn.submit').click(function(){
$(this).prev().click();
});
This works most of the times, but sometimes, when the wicket ajax stuff
includes references to 'this', the approach doesn't work, and wicket
tells me that the ajax request was stopped 'because of precondition'.
That's when he started bitching about the Wicket way of inlining
JavaScript, so I thought I'd be nice to hear some opinions :))
-- Edvin
--
View this message in context:
http://www.nabble.com/Wicket-and-inline-JavaScript-tp17402101p17417072.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
