I don't want to convince you anyhow. Just responding to your

On Sun, Dec 4, 2011 at 6:30 AM, Andrei Voden <are...@gmail.com> wrote:
> Hi. I have been developing for a while using Freemarker + some JS
> frameworks (like ExtJS, Dojo and JQuery) and Java as Model building on
> back-end. Now I hear lots of talks about Wicket so Im trying to understand
> pros and cons. After reading intro in Wicket I have mixed feelings. Below
> are my conclusions. I know Im biased but dont take it as offense. Instead
> rather as my misunderstanding since Im really trying to see if Wicket
> is thing to switch to.
> Pros:
> -Seems like this is good for companies where you have Java programmers that
> you can now utilize for building Front-end.

True, only if you are a pure consumer of component libraries.
Once you start writing your own components you'll need knowledge in JS/CSS.

> - Clean HTML code and all logic handled by Java.

This is a real pros, imo.

> - Quick to start building simple apps that fall into the box of the
> framework.
> - No JScript or HTML/CSS knowledge needed. Can separate easier Frot-end and
> Back-end developers --> easier to hire.

Partially true.
I think both developers should know something about the technology of
the other. Not details, but something. Otherwise they cannot meet in
the middle.

> Cons:
> - On other hand, as Front-end developer this looks weird to me since I feel
> like I don't have full control of JScript code.
> 1) Since Wicket uses Java for generating HTML/CSS/JScript UI controls for
> me meaning if I need to tweak those controls outside of their box it maybe
> problematic. In my experience any framework good until you start doing
> something different from what it was intended and then you can spend more
> time trying to do simple out of box thing then using native JScript. Is
> there JScript sources for Wicket controls?

Well written component should provide means to be extended and
customized. Most of the components should not generate JS and/or CSS.
The resources should be delivered with the components (see
ResourceReference) and the Java part of the component should just call
JS functions.
E.g.: AjaxRequestTarget.appendJavaScript("myJsLib.doSomething()")
and this call should be made so it is easy for the consumer of the
component to replace it with something else.

> 2) Prototyping: using Freemarker I can do changes and simply refresh page.
> In case of Wicket I need to recompile.

For prototyping this is OK but in long term the static types and the
unit tests are more valuable ;-)
But for prototyping (small app) you can use embedded Jetty (see
Start.java in Wicket's quickstart app) and this is quite fast.

> 3) Logic blocks: Looks like Wicket allows injection of values into HTML
> tags with wicket: attribute but how do you handle block logic like
> IF(condition) then {use HTML block1} else { use another HTML block}?

This is done at the server side:
if (condition) {
} else {

If the block is something really reusable then you should use Panel,
otherwise you can use Fragment instead.

> 4) Non html data templating: often during page generation I compose some
> AJAX data from FreeMarker inside tag. How do I do similar things from
> Wicket?

It is still possible. Wicket's Ajax behaviors can give you callback
url to the component at the server side. So you can ask the component
to do something and with AjaxRequestTarget.appendJavaScript() you can
return any string response (like JSON, XML, ...) and handle this
response with any JS templating system.
See the behavior used for
. It returns JSON which is consumed by JQuery UI autocompleter.

> 5) Is it harder/simpler to create custom UI controls in Wicket vs using say
> Dojo, ExtJS or JQuery?

The best is to integrate them. See 4) above for integration of Wicket
with JQuery UI component.
Once integrated you can give this component to a Java developer who
don't know JS at all and she can use it in her app.

> Andrei

Martin Grigorov
Training, Consulting, Development

To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to