Also, it seems like a lot of swing developers wish they had
something like
wicket, where they can do the form layout/design in xml and then do the
complicated bits in java. I think that although that isn't exactly what
F3
is, that's why people are excited by it.
i wouldn't like
On Thursday, 12 April 2007 02:40 am, Chris Colman escreveu:
Thanks, Igor, for taking the effort to answer my question. I so
understand
that one of the core vision statements is separation of concerns. I am
evaluating Click but haven't ruled out Wicket - just that some aspects
of
Exactly Igor,
thats why I prever wicket over any other framework. I absolutely hate html
generators or frameworks that generate there own html. I want freedom, not
only because i'm a controlfreak but mostly because I know that using a
framework that generates html in the end only leads to
Thanks, Igor, for taking the effort to answer my question. I so
understand
that one of the core vision statements is separation of concerns. I am
evaluating Click but haven't ruled out Wicket - just that some aspects
of
Click seem less cumbersome because separation of concerns is not a
Hi!
On 4/12/07, Philip Weaver [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.
In my extremely humble opinion, this is a wicket extension feature,
not a core wicket
On 4/11/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
After 40+ hours of more research, I did indeed find my style of coding
- and
it clicks. Page-based, ...
Another thing I don't agree with is that page-orientation is something
to aim for[1]. I believe a mixed model is more powerful[2].
u, this is not trivial? are you kidding?
let me write something up from memory
public class GuestBookPage extends WebPage {
private ListString comments=new ArrayList();
private String latestComment;
public GuestBookPage() {
add(new ListView(comments, new PropertyModel(this,
Why is this, and where are the modern Java web frameworks that don't try
to reinvent the concept of a website?
What a framework like Wicket tries to do is provide a programming
model that mimics programming like you would do for a desktop UI app.
Why? Because the model is much better suited for
On 4/11/07, Jason Roelofs [EMAIL PROTECTED] wrote:
I wonder if someone here can answer me this question: Why do more and more
Java frameworks try to push users farther away from the tried-and-true web
experience of having web pages that submit to servers and create other web
pages?
I'm not
On 4/11/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 4/11/07, Jason Roelofs [EMAIL PROTECTED] wrote:
I wonder if someone here can answer me this question: Why do more and
more
Java frameworks try to push users farther away from the tried-and-true
web
experience of having web pages that
@Igor:
It's not trivial because it requires complete understanding of the whole
Model system of Wicket. As per my actual question email, Martijn posted
exactly what I'm doing and how to solve it.
model is a core concept of the framework, so you better understand at least
that before posting
In one aspect it is a part of learning a library, on the other hand it fits
in with what I'm wondering: why the basic assumptions of building a web site
keep getting thrown out of the window with every new Java web framework. I
realize that people like the Swing framework for application
On 4/11/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Well, from what I've seen Rails sucks. Really. I find it ugly to look
at (JSP 1-ish), hardly has any abstraction and is all focussed on
short-term productivity gain. I'm way more interested in long term
gain (reuse, refactorability etc)
I started this thread because I wish Wicket would support the following
feature.
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.
If layout is a problem - find a solution. I wish that Wicket had a
i thought you were using Click?
anyways, what you want is possible, like ive mentioned, but is not the
primary focus of wicket. wicket is about separation of concerns. that means
letting the designers design the markup with all its pretty css and images,
rather then making developers try to
Thanks, Igor, for taking the effort to answer my question. I so understand
that one of the core vision statements is separation of concerns. I am
evaluating Click but haven't ruled out Wicket - just that some aspects of
Click seem less cumbersome because separation of concerns is not a priority
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.
On 4/11/07, Philip Weaver [EMAIL PROTECTED] wrote:
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
After 40+ hours of more research, I did indeed find my style of coding - and
it clicks. Page-based, component-based, object-oriented web interfaces
driven by Java code with automatic html rendering.
http://click.sourceforge.net/
Phil
On 4/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
After 40+ hours of more research, I did indeed find my style of coding - and
it clicks. Page-based, component-based, object-oriented web interfaces
driven by Java code with automatic html rendering.
http://click.sourceforge.net/
Phil
On 4/8/07, Eelco Hillenius [EMAIL PROTECTED]
After 40+ hours of more research, I did indeed find my style of coding - and
it clicks. Page-based, ...
Another thing I don't agree with is that page-orientation is something
to aim for[1]. I believe a mixed model is more powerful[2].
There's a lot more that can be said about the different
Hello, I've been following the discussions here, and this one caught my eye.
Does this mean that Wicket is ill suited for example for creating dynamic
forms that are built dynamically at runtime after reading some page
definition file from xml or some other data store. I havent looked into
Wicket
Hello, I've been following the discussions here, and this one caught my eye.
Does this mean that Wicket is ill suited for example for creating dynamic
forms that are built dynamically at runtime after reading some page
definition file from xml or some other data store. I havent looked into
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Actually I just did this at work but I used fragments rather than
panels. We just need a simpler datatype-html widget look up so I just
went with fragments so that I don't need to build a bunch of java class
and html files. The fragments are
search the list and wiki for bean panels. there is also a bean panel project
in wicket-stuff although i dont know how usable it is.
-igor
On 4/8/07, Philip Weaver [EMAIL PROTECTED] wrote:
I am interested in creating a complex form in Java code without needing to
manually configure any html
I'm just going to echo what Eelco originally said: HTML is quite good
for defining forms. I'm glad people have found ways to generate them
from XML or whatever (and for some purposes I'm sure that's best), but I
would encourage new users to keep an open mind about plain HTML
templates for
I am interested in creating a complex form in Java code without needing to
manually configure any html for that form. In Swing for example, when you
create a text field, it automatically has a default representation/view.
Not a good comparison though, as Swing doesn't generate markup. Like
27 matches
Mail list logo
