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
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
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
reading, I
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 rather
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 cas...@jbr.dk wrote:
restlet is for building services
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
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 never
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:
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
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:
I'm trying to implement credentials
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
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
, 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 nicely (and with
somewhat cleaner code
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. A
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
.
-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 upon Enum and EnumSet
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
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:
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
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
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
Casper Bang wrote:
In Wicket in Action it's
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
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:
Ok. It sounds like the general philosophy behind Wicket is server side
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
24 matches
Mail list logo
