I understand that Ajax is not that easy, so maybe it's impossible with Click
to offer the same level of "magic" like it usually does.
Not sure where you see "magic" but one of the things that attracted me
to Click is that there was no magic. It is stateless, URLs are
predictable and it follows the DRY principle.
I mean by magic: Automapping, Autobinding, very good defaults for many
components, that they have predictable and easy to learn API, the nice
toString(onRender) so that templates remain extremely small, and sure,
the fact that it's totally customizable if needed (but I haven't use
this - I guess it's more as an insurance for the management :) )
Unfortunately, for me this "Behavior" functionality doesn't sounds "too
natural". It also feels just too much like Wicket.
I think we need to be careful of trying to be different just for the
sake of it. This is open source after all, and we should borrow good
ideas from other frameworks.
Sure, but only the idea :). I was just trying say that their approach to
problems(from the user's standpoint, as what he needs to do to achieve a
task) is not simple at all, even if that slogan is overused.
I can't even use that word anymore with Click cause it's automatically
associated with them :(.
Not saying Behavior is good but I do
think it accurately describes the feature.
Well, even if others already use that name, the naming still makes me
associate with
so other concepts :). I have no idea what other name would suitable:
"Transformer", "Changer", "Morpher" ?
Is it the Behavior concept that you find difficult or is it the
implementation that is complex?
I can't say much about the implementation yet, but so far I find quite
allot of what the user must code to achieve a simple result (compared to
the usual stuff in Click):
https://hudson.apache.org/hudson/view/Click/job/Click/javadoc/docs/user-guide/html/ch04s04.html
I understand that Click wants to remain JS framework independent, but
maybe some simple helper JS or shortcuts wouldn't be so bad - even if
they're in click-examples only so that users can copy and paste them (s
they already do with most of the stuff from click-examples :) ).
For the example from ch 4.4:
--> 1. would be easier if Click would simply provide his unique
default ID like it usually does for components. I think there would be
no need for the user to specify or care about it, only in exceptional
cases. This could also propagate to the template too, so that the user
doesn't code it over and over again.
--> 2. "<div id="result">" - for most cases would be interesting if
this placeholder could be also generated by Click too, since the Page
already knows that it's Ajax in there.
--> 3. In ajax-behavior.htm, I suppose something like makeRequest will
be called most of the time, so maybe some generic helpers would be
practical - for the case the user doesn't need the full blown
click-jquery or other click-xxxx libraries.
What I mean with all this stuff (from the user's view), is that it would
be cool if Click like usually does, would do everything behind the
scenes for 80% of the cases and the user would only need to do maybe the
following or less:
--------------------
public class AjaxBehaviorPage extends BorderPage {
public ActionLink link = new ActionLink("link", "here");
public DivPanel result = new DivPanel();
public AjaxBehaviorPage() {
link.addBehavior("onAjaxAction", this);
addJS(JQUERY, "customScript", this, result);//magic with
getHeadElemnts with jQuery.
}
public ActionResult onAjaxAction(Control source){
return new ActionResult("......", HTML);
}
public void customScript(ActionResult data, Control result){
result.setContent(data.getContent());
}
--------------------
so ajax-behavior.htm could look like:
--------------------
Click $link to call the server using Ajax.
$result
--------------------
I assume you have looked at the
Behavior Javadoc? Perhaps it needs further explaining or more
examples?
Yes. For some of the new classes the Javadoc is not much, but for other
it's quite allot :). More examples? yes, but I'm not sure about the
explanations.
Regarding the documentation:
4. "...Note, if you want to send a specific response to the client or
perform a redirect you have to do that from the onSecurityCheck() event,
since other Page events are not processed."
---> Is there an example how to send a specific response from
onSecurityCheck? since it's not returning an ActionResponse to be able to
returns something to the client.
I'll add an example, but essentially you'll have to render directly to
the HttpResponse. Normally one would redirect to another page, but
redirect is not supported directly by Ajax.
Other questions to chapter 2.7:
5. can the pageAction parameter be configured/renamed by the user or is it
hardcoded in Click?
I guess one could create a custom ClickServlet to change it...
I'm asking since in some applications this parameter can be "reserved"
and need for other things: it's so general (it's not in the Click
namespace). Other applications could need it because of
legacy, when migrating from another framework to Click (e.g. just had a
small CMS module using it. I'm not allowed to change it cause the
rewrite rules (that make REST like URLs) are outside of the project.
In fact it would be cool if other Click constant names could be simply
overridden too.
C.
https://hudson.apache.org/hudson/view/Click/job/Click/javadoc/docs/user-guide/html/ch04s04.html
---> It would be nice if it would be possible to use that example without
an anonymous class - the same way it's possible with other listeners. E.g.
link.addBehavior("onAjaxAction").
Where "onAjaxAction" is a method on the Page?
Yes, or just like with the buttons or action links, but I forgot the
target, so: link.addBehavior("onAjaxAction", this). :).
It would be nice if it would be possible to avoid anonymous classes
and have nice "flowing" code in pages :).
regards,
Andrei.
