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 tha
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
>
>
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 f
> 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
> pr
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 hor
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
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 probl
> 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 comp
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
th
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 repro
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
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)
> 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 bu
@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
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
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 n
> 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
u, this is not trivial? are you kidding?
let me write something up from memory
public class GuestBookPage extends WebPage {
private List comments=new ArrayList();
private String latestComment;
public GuestBookPage() {
add(new ListView("comments", new PropertyModel(this, "comments")
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
> > 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 differen
> 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 PROT
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:
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 forms
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
-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 na
> 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
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
> 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
w
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. If
I decide I'd like to change the view, I set a new UI object.
It basicall
29 matches
Mail list logo
