Inlined...
On 4/11/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> I wish that each form or form element element had a default renderer and
> would render itself without needing to be embedded in some other html
file.
Yep, gotcha.
> If layout is a problem - find a solution.
It isn't a problem. It's a core assumption that Wicket works on
markup: 'enabling component-oriented, programmatic manipulation of
markup'.
I understand. I also understand Wicket's core vision includes separation of
concerns.
Also, since you think Click answers what you are looking for, I wonder
how this is so different?
Java:
Form form = new Form();
textField = new TextField("search");
form.add(textField);
Select typeSelect = new Select("type");
typeSelect.addAll(new String[] {"ID", "Name", "Age"});
typeSelect.setValue("Name");
form.add(typeSelect);
Html:
$form.startTag()
<b>Customer</b> ${form.fields.search}${form.fields.type}${form.fields.go}
$form.endTag()
I'll assume that the $ signs are Velocity tags and you are refering to
Click. Yes, Click does integrate Velocity tags - but for the most part you
won't have to use them. If you create a form for example in Click, it
renders the entire form and its components for you and layout is
customizable via a set of flags and via CSS. Everything is coded in Java,
has default renders, and is customizable.
Besides whether that's better than how Wicket does it or not, you
really are referring to those components in HTML right?
To some extent perhaps. But the title of this thread is "Creating Entire
Forms in Java Code Only?" Click does create and render all forms in code
(without Velocity) using default rendering which is customizable. Perhaps
Click just needs more configurability is its layout component for general
use. Click also renders table automatically. Click also supports Panels.
I recommended Echo (and GWT if you like) as there you work with layout
managers rather than with markup. I thought that's what you wanted
being a Swing guy. So I was surpised to learn you thought about Click
now (though there's nothing wrong with that of course).
I don't mind working with HTML markup. But object-oriented programming
languages like Java can allow us to abstract away from the tedium and
cumbersomeness of rendering html; e.g. encapsulation.
If you mean that you prefer components to directly spit out HTML,
that's very easy with Wicket, just like:
protected void onComponentTagBody(MarkupStream markupStream,
ComponentTag openTag) {
getResponse().write("<foo><bar>udududud</bar></foo>");
}
etc. But like we stated before, this wouldn't be the recommended way
of working with Wicket. More of a break out option and optimization.
I understand. Thanks. One of Rail's mantra is convention over configuration.
Being able to render default HTML for common types of controls seems
conventional - it seems less cumbersome. I am not disrespecting Wicket - I
appreciate Wicket but I wish that it were less cumbersome to use for UI
programmers.
Eelco
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/wicket-user
