> restlet is for building services not uis, that quote makes absolutely no
> sense.
>
While I agree the quote smells of FUD, one doesn't necessarily exclude the
other. The beauty of REST is its statelessness, addressability,
representation negotiation, caching and other ways it embraces HTTP rathe
these restlet-like services provide anything to help you
> generate the ui? do they have jstl tags? components? templating?
> nothing out of the box right? you have to glue that yourself on top of
> them.
>
> -igor
>
> On Wed, Apr 1, 2009 at 10:05 AM, Casper Bang wrote:
> &g
Allow me to jump in, since it kinda touches on a related subject we
discussed earlier today:
http://www.nabble.com/Wicket-and-(or)-restlet-tt22822162.html#a22833918
What I understand from Jamie is to do kind of the reverse from what I
wanted, that is, hook into the raw data Wicket is using to serv
> Peter Thomas did a great side by side you should checkout:
Good article, if perhaps a bit one-sided. I can understand how
separation-of-concerns/composability comes slightly more natural to Wicket.
However the performance, flexibility and component repertoire of GWT along
with steadily more capa
> P.S. people say my article is "one sided" but no-one can explain *why ;) -
> ok, ok this has been discussed to death in the comments there ...
>
I should mention I love wicket (coming from JSF) but has only limited
exposure to it while having no experience at all with GWT. However while
readin
Use Lombok (http://projectlombok.org/), it allows you to generate
setters and getters through annotations:
@Getter @Setter private String name;
/Casper
David Chang wrote:
Martin,
Thanks for your input. My intention is how to get rid of these boring
setters/getters from service beans that a
Hi Ashley,
I actually wrote the list regarding a similar idea about a year ago. It
seems like a handy thing for RAD and for newbies struggling with keeping
simple CRUD pages in sync. However I can offer nothing but an
encurraging "great idea, go for it". :)
/Casper
Igor Vaynberg wrote:
> i dont
Pardon the (possible stupid) question, I'm new to Wicket but is quite
excited about the simplicity it seems to promote over JSF.
What's the usual way of pushing context on to a website and have it
passed along, such as to remain stateless? In JSF you would typically
create some hidden inputs w
Ok. It sounds like the general philosophy behind Wicket is server side
statefulness. I was kind of hoping this was not the case. Just out of
curiosity, haven't anyone tried serializing and embedding state out on the
webpage that could then be POST'ed between requests - a kind of hybrid model
betwe
Right - that would only work for POST since I believe the HTTP RFC limits GET
requests to 2 or 4K. By experience, in JSF, pushing state this way to the
webpage (base64 encoded and pk encrypted) has the benefits of request scope
(no thread-safety issue, no multi-browser issue etc.) while maintainin
base64 every page into the result and the other way
> around is just way way to expensive.
>
> Did you encounter any real issues with state on the server or is this
> again premature optimization??
>
> On 11/19/08, Casper Bang <[EMAIL PROTECTED]> wrote:
>>
>>
In "Wicket in Action" it's mentioned briefly how one could use a
SimpleAttributeModifier to limit the text length of an input, by binding to
a JPA @Column annotation and its length attribute. This sounds nice DRY to
me (albeit perhaps a bit expensive?!) so I gave it a try:
protected String ge
Oh wow, that's a virtual gold mine. Thanks!.
/Casper
jWeekend wrote:
>
> Casper,
>
> Something like
> http://cwiki.apache.org/WICKET/how-to-do-things-in-wicket.html this ?
>
> Regards - Cemal
> http://www.jWeekend.co.uk http://jWeekend.co.uk
>
>
I'm trying to use the build-in authentication and authorization stuff of
Wicket (1.4-rc1), as demonstrated on the examples page:
http://wicketstuff.org/wicket13/index.html (there does not appear to be a
http://wicketstuff.org/wicket14/index.html).
However I can not see org.apache.wicket.authoriza
Session/state-fullness is the no. #1 concern for me about Wicket. If you
like to keep an eye on certain object trees during runtime, as an
alternative to external profiling (which I've always found cumbersome)
you can use TopCoders memory usage component:
http://software.topcoder.com/catalog/c_
What attracts me to Wicket is how it tries to do as much in type-safe
Java code as possible, so I was a bit surprised with the finding that
the org.apache.wicket.authorization stuff is not based upon Enum and
EnumSet but rather type-unsafe string tokens.
Are there good reasons for this design
stuff somewhere.
-igor
On Thu, Nov 27, 2008 at 10:33 AM, Casper Bang <[EMAIL PROTECTED]> wrote:
What attracts me to Wicket is how it tries to do as much in type-safe Java
code as possible, so I was a bit surprised with the finding that the
org.apache.wicket.authorization stuff is not based
Yeah. First I actually didn't understand why until Igor pointed it out.
I'm no longer using wicket-auth-roles, if one can live with the roles
being defined along side the authorization code it works quite nicely
(and with somewhat cleaner code). I ran into another issue however,
trying to model
On Thu, Nov 27, 2008 at 6:56 PM, Casper Bang <[EMAIL PROTECTED]> wrote:
Yeah. First I actually didn't understand why until Igor pointed it out. I'm
no longer using wicket-auth-roles, if one can live with the roles being
defined along side the authorization code it works quite ni
While I understand the Wicket authors do not want a magic framework, I
wonder if anyone else than me ever wished for a "development mode" or
option on the error page when protyping and receiving the very typical
"org.apache.wicket.WicketRuntimeException: The component(s) below failed
to render.
I'm trying to implement credentials memory functionality for a login
form using cookies. I know there's an official example
(http://wicketstuff.org/wicket13/signin2/?x=7*:org.apache.wicket.examples.signin2.SignIn2)
however it simply delegates to some panel which is not available as
source on th
here would you show login page, without anything pre-filled
because
// they're not already signed in and they don't have a cookie to sign
them in
setResponsePage(YourLoginPage.class);
}
}
}
On Tue, Dec 2, 2008 at 9:26 PM, Casper Bang <[EMAIL PROTECTED]> wrote:
James Carman wrote:
The browser's saved passwords support doesn't transmit your password over
HTTP along with the rest of the markup, though. It just remembers it and
auto-populates it for you once it receives the HTML from the site. So, it's
as unsafe as your computer is (hopefully you use a p
Yeah, I asked about this last week or so when running into the same
problem. I now also do it the class way, and although that does feel
better than using strings, in my opinion it still isn't type safe. It
gives no syntax lookup and people are free to write Object.class which
will compile just
Work in Denmark, live in Canada (don't you just love technology?) and
planning my strategy for converting my JSF-masochistic colleagues over
to try Wicket. ;)
/Casper
Wadi Jalil Maluf wrote:
Argentinians working on wicket and mobile apps integration
Wadi
-Mensaje original-
De: N
Sounds interesting, although it would be nice if you could mention a trick or
two such as to provide us with a little more info. I'm guessing its
different from what you'd find in the wiki?!
Casper
Jonathan Locke wrote:
>
> Well, over the break here I've started something I swore I would neve
26 matches
Mail list logo