Yet another Wicket quick start application...
For anyone interested, I've made public yet another quick start application that brings together Wicket, Spring 2.5 and Hibernate. The app features a basic CRUD framework based on wicketstuff-crud. The CRUD framework uses bean annotations to define CRUD properties. It also uses the excellent InMethod Grid component for the list view. Link: http://apptizer.googlecode.com/ Cheers, - P -- View this message in context: http://www.nabble.com/Yet-another-Wicket-quick-start-application...-tp22068362p22068362.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: @SpringBean vs getApplication().getDao()
To answer your question, yes spring beans are singleton by default. The @SpringBean annotation works roughly like this: in your Application class, you set a ComponentInstantiationListener which gets called every time a Wicket page/component is instantiated. The particular listener that gets set (SpringComponentInjector) takes care of setting the component's fields that are annotated with @SpringBean with the appropriate beans found in the spring context. My guess is that the Listener isn't being configured properly, and that is why your @SpringBeans are null... Sergey Podatelev wrote: Okay, this question might actually be more related to Spring, but I'm completely lost here, and my question on Spring forums usually don't get any replies, so I hope Wicket community might help as it usually does. I'm using JCR, and have a RepositoryDao bean configured in applicationContext.xml. RepositoryDao has a template property which points to an instance of JcrTemplate in applicationContext.xml, all repository access is performed through that template. I have an AccessPage which has a RepositoryDao injected via @SpringBean. There is an inner class Form on that page, it has a default submit button and three submit buttons that skip default processing and perform their own operations onSubmit(). Both default button and skip-default-processing buttons use the same repositoryDao property of AccessPage to perform certain operations on repository. I noticed that when I actually open that AccessPage, there's a new RepositoryDao object created, and it's template property is null. When I press any of those non-default submit buttons of the form, everything works fine. But on default button onSubmit(), I see that there's yet another insance of RepositoryDao created, and it's template is also null, which leads to NullPointerException. I assumed that beans configured in applicationContext.xml are actually singletons, so there won't be any new instances of such nodes upon pages-with-injections instantiation. Regardless of whether that assumption is correct/incorrect/my-god-rtfm, I still won't understand why default submit button reaction is NPE as it uses same partnershipDao property of AccessPage. Could someone please elaborate some internal differences of the annotation-based approach as opposed to storing DAOs in Application object. In the latter case it's quite clear that there's a single instance of RepositoryDao as a property of MyApplication which is pulled on ((MyApplication) Application.get()).getRepositoryDao(). Thanks. -- sp -- View this message in context: http://www.nabble.com/%40SpringBean-vs-getApplication%28%29.getDao%28%29-tp22061472p22072806.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Mount URL to another host?
If you want it external to Wicket, you probably want to use a ServletFilter... something like: http://tuckey.org/urlrewrite/ Zach Cox wrote: I feel dumb for even asking this, as there's got to be an easy way, but my brain is blocked today... I need a URL on my site, say http://mysite.com/something to redirect to another site entirely, say http://othersite.com. Is there some IRequestTargetUrlCodingStrategy that will do this? Or am I totally on the wrong track by looking there? Thanks, Zach -- View this message in context: http://www.nabble.com/Mount-URL-to-another-host--tp19921980p19922453.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: job postings
Ditto... http://www.inertiabev.com/inertiabev/page/jobs.jsp From the company that brought you Brix CMS. (http://code.google.com/p/brix-cms/) We are based in Napa, but are willing to consider telecommute. -- View this message in context: http://www.nabble.com/job-postings-tp19602122p19905140.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I use the wicketdate-time stuff with DateTime on my model?
We use DateTime/LocalDate in our entities as well. It's easy enough to roll your own form components. See the patch and zip file attached to this issue, you can probably just put those classes in your own project and run with it. https://issues.apache.org/jira/browse/WICKET-466 The patch is meant to handle java.util.Date, and Joda DateTime and LocalDate all at the same time. Now that Wicket FormComponents are generic though, I think it's better to just have separate FormComponents and Converters for each class. Ned Collyer wrote: Its a requirement for me that my domain entities have DateTime. I'd like to use wicket-datetime (as described here) http://www.nabble.com/my-domain-model-and-Joda-Time-td15660961.html#a15660961 I can see its internals are all DateTimey which is AWESOME!! What is the easiest / quickest way of getting this stuff to work with DateTime in my domain model. I'm running 1.4m1. What I'm toying with is compiling the project and applying the patch from http://issues.apache.org/jira/browse/WICKET-466 But I'd rather have a simpler way - eg, extend or reimplement a class. -- View this message in context: http://www.nabble.com/How-can-I-use-the-wicketdate-time-stuff-with-DateTime-on-my-model--tp19872583p19911816.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Cart: open-source e-commerce wicket app
James, If you need any CMS functionality at all for your cart project, please have a look at: http://brix-cms.googlecode.com/ For example, you could incorporate your cart panels as tiles inside of Brix. msc65jap wrote: Is anyone interested in contributing to an open-source e-commerce wicket engine? I was thinking of calling it WicketCart. I have written a primitive version which serves as a good foundation to build upon. I have a new client, a royal college, requiring an e-commerce web app so just pondering the idea of WicketCart. If other developers are interested in contributing then I will make it open-source. I have written it so far using Spring and Hibernate but very open for it to additionally be implemented for other frameworks. If anyone wants specific details or wants to discuss it a bit more, then feel free to email me. Best, James. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Wicket-Cart%3A-open-source-e-commerce-wicket-app-tp19184933p19190630.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page models
I don't tend to use models in my pages. I tend to think of Pages as having more to do with site navigation, as opposed to what is actually displayed in them... (you would then add genericized panels, like ViewOrderPanel, etc., to a page.). John Patterson wrote: Yeah guess I will do that. was just wondering if I was in the minority using models in my pages. igor.vaynberg wrote: you can always create your own subclass that is generified, and use that -igor On Wed, Aug 27, 2008 at 3:17 AM, John Patterson [EMAIL PROTECTED] wrote: Hi, in almost all my pages I set a model for the page and then need to retrieve it using the un-typesafe getDefaultModel(). Or I implement a typesafe getModel(). I was just wondering if others really normally use pages without models? If not maybe Page should be generified? JD -- View this message in context: http://www.nabble.com/Page-models-tp19178165p19178165.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Page-models-tp19178165p19190800.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Wicket + Hibernate project- Transaction solutions? Java EE w/ Wicket?
You can use annotations or spring-javaconfig with Spring if you don't want to go through too much XML configuration. That criticism is really unwarranted these days. The annotation-style configuration is very similar to how Guice works, whereas spring-javaconfig is basically like writing the spring.xml file in Java code. The latter is nice in that all the wiring is centralized, but you still get the benefits of working with a Java IDE, such as refactoring or searching for occurences. There's probably some easy way to hook Guice up with the Spring transaction manager, but I've never tried. And yes, you should be able to run Wicket in an EJB3 Container, but you'll have to deal with some boilerplate code that will allow you to inject your EJB3 services into Wicket components... Personally, I would recommend going with Wicket, Spring and Hibernate (or JPA) via spring-javaconfig. jpswain wrote: I'm just curious what everyone is using for transaction management. I have been working with Wicket for a while now (and loving it) on a pet project that also uses Hibernate and Guice. I'm realizing now that I might need/want transactional support for a couple parts of my app. I don't have any experience with Spring or Java EE or EJB, but have been avoiding Spring because of what I have read and seen online with so much XML-coding. Is it possible to use spring transaction module by itself and without too much XML? I'd really appreciate hearing what y'all are you guys using for your transactional needs. Also is it possible to run a Wicket-based project inside a JEE container like Glassfish or JBoss AS directly to take advantage of EJB JTA, or would that require something like Seam + wicket-seam integration? If anyone has recommendations on where to get started with transactions, that would be great too. Thanks! J -- View this message in context: http://www.nabble.com/My-Wicket-%2B-Hibernate-project--Transaction-solutions--Java-EE-w--Wicket--tp19127403p19127522.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another Brix Project...
Wow. Thanks for the heads up. We'll email those guys and let them know of our project just to make sure we're not working on two very similar things at once. jwcarman wrote: http://blog.playlouder.com/2008/03/11/about-brix/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Another-Brix-Project...-tp19109800p19112833.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FeedbackPanel default outputMarkupId = true
Does it make sense to have outputMarkupId default to true for FeedbackPanel?
Use case:
somePanel.add (new OnChangeAjaxBehavior() {
protected void onUpdate (AjaxRequestTarget target) {
// do stuff,
Session.get().info (did stuff);
target.addChildren (getPage(), FeedbackPanel.class) ;
}
});
This code will work from anywhere in the component hierarchy, regardless of
which component added the feedbackpanel, without the owning component
having to call feedback.setOutputMarkupId(true)...
I could just as well subclass FeedbackPanel but this seems like a common
enough case that it makes sense to build it into the core...
--
View this message in context:
http://www.nabble.com/FeedbackPanel-default-outputMarkupId-%3D-true-tp19041186p19041186.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: getter setter strategy for models
Have you tried private/default scoped setter methods, and would that be an okay compromise for what you want to do? lars vonk wrote: Hi, I realized that when I have a getter, but no setter for a certain property on a Model object for form components it fails with the message that it can't find a setter. When I don't have any getters and setters the binding still works since it uses field access. I expect this intended behavior, right? If so, what are your thoughts about changing this that for instance to be able to define a sort of property strategy for binding values to your model object. I would like to have getters for my model objects, but no setters. Or am I overlooking something here and is it already possible to define the property strategy? Regards, Lars - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/getter-setter-strategy-for-models-tp18810507p18820993.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sneak peek - brix - wicket/jcr cms
Hi Dipu, Thanks for looking into Brix. If you can identify any specific areas where we could improve our documentation, let us know. wicket user-2 wrote: i am very impressed with what i see there, i had created a simple POC in my company for managing the contents in our wicket apps, i can see pretty much everything i used here like jackrabbit, code mirror, rich editor etc looking forward for the release and some more documentation. you guys rock many thanks Dipu On Tue, Jul 8, 2008 at 11:06 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: a few of us have been quietly working on a wicket/jcr cms called Brix for a while now. it is almost at a point where we are ready to release a beta, just waiting for wicket-m3 build to go official. in the meanwhile, if you are not afraid of building from source and want a sneak peek, you can check it out here [1]. brix is more of a cms framework/library than a full blown cms. it is designed to be integrated into wicket applications that require cms functionality as part of their feature set. for example, at my company we have built a set of ecommerce tiles (brix tiles are dynamic components that can live inside a cms page) that allow us to build webstores on top of brix. brix includes a url coding strategy (which will hopefully become part of wicket 1.5) that allows for stateless pages as well as url contribution from tiles and query/indexed parameter mixtures. it has been designed with scalability in mind although we have not yet built a caching solution, nor tested if one is necessary. to hopefully preempt some common questions: brix uses a simple plugin system to allow extensibility. we did not use osgi because our time is limited and running wicket inside osgi or osgi inside wicket is not straight forward yet. will we switch to osgi later? maybe. we did not use spring because we did not need the overhead and spring's jcr support is broken because its jcrsessionfactory does not support multiple jcr workspaces so we would have to roll our own anyways. suggestions, feedback, etc are welcome as well as any help. we have not been working on this very long so it is not extremely polished yet. for more info see the website. [1] http://brix-cms.googlecode.com -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/sneak-peek---brix---wicket-jcr-cms-tp18350188p18370795.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
I second Matej here... maybe instead of GenericPanelT, GenericFragmentT,
etc. you could name it something more explicit. Some examples:
SingleModelPanelT
ModelBoundPanelT
It took me the better part of one day to convert a partially genericized
project (we started out with 1.3 then switched to 1.4 mid-stream). The
project had 100k++ LOC. The resulting code is much easier to read.
Another thing that you can consider adding to the core... a utilities class
'Models' to wrap models so you don't have those pesky all over the place:
public MyPanel(String id, IModelInteger model)
{
super (id, Models.compound (model)); // wrap model in a
CompoundPropertyModel
}
Matej Knopp-2 wrote:
There is one thing that helped me quite a lot when migration the
project I'm working out. I've created GenericPanel,
GenericWebMarkupContainer and GenericFragment classes. In most cases
the only change was renaming PanelMyClass to GenericPanelMyClass.
I was wondering, even though those classes were farily simple, we
might want to include them in Wicket anyway, for the sake of
consistency and convenience.
-Matej
On Mon, Jun 30, 2008 at 12:28 PM, Johan Compagner [EMAIL PROTECTED]
wrote:
i looked through the code and it is fine by me.
Lets test this then in a Build and see what people think of this.
On Mon, Jun 30, 2008 at 8:54 AM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
unit tests are fixed...
-igor
On Sun, Jun 29, 2008 at 11:16 PM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
I'm guessing somewhere this week or so. We need to flush out the unit
test failures and get some preliminary feedback. Also we need to have
time available to actually build the release.
My time is limited because we're in the final stages before publishing
and I have to read our book twice or so.
Martijn
On Mon, Jun 30, 2008 at 2:36 AM, James Carman
[EMAIL PROTECTED] wrote:
What sort of time frame are we looking at for a release with this new
generics paradigm?
On Sun, Jun 29, 2008 at 3:54 PM, Igor Vaynberg
[EMAIL PROTECTED]
wrote:
On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier [EMAIL PROTECTED]
wrote:
Hi,
I've just converted two projects to the new generics setup and
everything
worked out nicely.
I think this is how generics should be applied to Wicket.
Igor, thanks for your hard work on this.
wasnt just me :)
-igor
Sven
Igor Vaynberg schrieb:
development of the 1.4 branch has been quiet lately, this is
because
the core team has been busy working on an alternative way of
generifiing the framework. an early result of that effort can be
found
here [1]. The key difference in [1] is that we have decoupled the
component from the type of the model.
here is the list of major differences:
(1) only components that use their model have a generic type
(components you are likely to call getmodel/getmodelobject on as a
user). so far these are link,form,formcomponent
subclasses,listview,listitem,(other repeaters will follow soon).
this
allows for typesafety where it makes sense, and eliminates a ton
of
noise from code. we will generify others upon request if a good
usecase is provided and we think it is widely applicable.
(2) non-generified components do not have IModelT get/setModel
and
T
get/setModelObject, instead they have IModel?get/setDefaultModel
and
Object get/setDefaultModelObject. this clearly expresses that the
default component model is not tied to the type of component. this
is
a bit of a pain from the code migration point of view, but we
think
is
worth the effort. generifyed components are free to implement the
old
IModelT get/setModel, etc, but have to keep the unsafe cast
inside.
see ListItem for an example.
basically we feel this is a much cleaner way then what is 1.4m2.
this
is a call for confirmation/discussion from our user base. do try
to
port a small project or a part of a larger project you are working
on
to the [1] branch to see how the new api feels. if we do like this
more the new branch will be merged into what will be 1.4m3.
[1]
https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
-igor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Become a Wicket expert, learn from the best:
Re: generics
add (new LinkPerson(edit, person) {
public void onClick () {
setResponsePage (new EditPersonPage (getModel()));
}
});
This code makes a lot more sense if it is inside a repeater...
Rodolfo Hansen-2 wrote:
I too like this compromise alot
Although I don't see a good use case for generifying Link ?
Am I missing something?
On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho [EMAIL PROTECTED]
wrote:
On Fri, 27 Jun 2008, Igor Vaynberg wrote:
since no one complained, should we apply this change over the weekend?
and soon thereafter release m3?
I prefer this over M2. Even though:
user). so far these are link,form,formcomponent
Link might be better without the type parameter. It's no big
deal though.
And yes, it would be good if for example Johan and Gerolf
who have invested a lot of effort on the generification
could have a closer look and tell what they think before
proceeding.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations OyURL: http://www.ri.fi/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/generics-tp18083910p18222901.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How reliable Validators are?
Another difference, if you have to do a database roundtrip (which you will likely need to verify a password) then the code for the validator is a bit more complicated. You have to take into account the fact that this gets serialized/deserialized as part of the page so you can't just pass a DB connection or hibernate session in the constructor. Eelco Hillenius wrote: But can you please explain, why wouldn't you use validator for this? I think that's just personal preference. Validators are reusable, while putting a check in onSubmit isn't. Whether that matters depends on your project and the context you do the check in. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/How-reliable-Validators-are--tp17697642p17699825.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How reliable Validators are?
That doesn't work either... b/c the validator instance has already been set... @SpringBean would work, but the Validator will need to manually invoke the Injector in it's own constructor. Or you can use http://code.google.com/p/salve/ which is what we do. jwcarman wrote: I meant from some other class (a Component) that had the bean injected. That class could then pass its injected dependency into the validator's constructor. On Fri, Jun 6, 2008 at 3:53 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: not without manually injecting the validator or making validate an inner/anon class so it can access component's fields. -igor On Fri, Jun 6, 2008 at 12:46 PM, James Carman [EMAIL PROTECTED] wrote: You can, however, pass in an object obtained via injection with the @SpringBean annotation. On Fri, Jun 6, 2008 at 3:42 PM, Patrick Angeles [EMAIL PROTECTED] wrote: Another difference, if you have to do a database roundtrip (which you will likely need to verify a password) then the code for the validator is a bit more complicated. You have to take into account the fact that this gets serialized/deserialized as part of the page so you can't just pass a DB connection or hibernate session in the constructor. Eelco Hillenius wrote: But can you please explain, why wouldn't you use validator for this? I think that's just personal preference. Validators are reusable, while putting a check in onSubmit isn't. Whether that matters depends on your project and the context you do the check in. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/How-reliable-Validators-are--tp17697642p17699825.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/How-reliable-Validators-are--tp17697642p17702421.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
igor.vaynberg wrote:
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
((imodel)field.get(this)).detach();
}
}
onDetach();
}
+1
I'm also for moving getModel()/getModelObject() out of Component and only
putting them in things that really use models, like Label and
FormComponent...
I agree, though, that this should probably wait for 1.5...
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17652189.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Eelco Hillenius wrote: [x] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [x] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. We are on 1.4 trunk on a huge project ( 100k LOC) which we are still in the middle of converting as we started out on 1.3.x. I can say without a doubt that generic components do get in the way, and that there are only a few cases where we actually call getModelObject(), for which casting is an acceptable workaround. I would go so far as saying, the concept of 1:1 Model:Component can be misleading. As a number of previous posters have indicated, and I can validate first-hand, most components are not model backed. In my case, and I even have a few components that are backed by more than one model. So another angle to consider is completely decoupling Model from Component. Instead you might have setModel(String id, IModel?) and getModel(String id)... The old getModel() would be the equivalent of calling getModel((String)null)... I understand that this is a huge API break, with marginal value, but it does express the Model:Component relationship a lot more clearly. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17628984.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 1.4 with only generics and stop support for 1.3
+1 (has anyone voted -1 yet?) Martijn Dashorst wrote: This thread is for voting only. Use the [discuss] thread for voicing your opinion or asking questions. This makes counting the votes much easier. The discussion on our development list makes it clear that a lot of folks are anxious for generified models. Most users if not all wish us to release a quick release which is 1.3 + generics. The consequence is that the core team will stop to support 1.3, and that everybody that wishes updates will have to migrate to 1.4, and upgrade to Java 5. Everybody is invited to vote! Please use [ ] +1, Wicket 1.4 is 1.3 + generics, drop support for 1.3 [ ] -1, I need a supported version running on Java 1.4 Let your voices be heard! Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.2 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-vote--Release-1.4-with-only-generics-and-stop-support-for-1.3-tp16090054p16201965.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Doubt in wicket and multiple views
So long as everything runs in the same webapp, you should be able to use the same model. From a wicket application, you can always get to the request object to get to the virtual host, so you can use that info to present a different view. Mathias P.W Nilsson wrote: Hi! I have one model and 4 different web applications. All webapplications is using the same model but different views. There is Different virtual hosts on the same server. Can I use wicket for this? ie Domain1.se, Domain1.com, Domain2.se, Domain2.com same server different virtual hosts same model with Wicket. -- View this message in context: http://www.nabble.com/Doubt-in-wicket-and-multiple-views-tp15306737p15307866.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Evaluating Wicket
Hi Rene, Some answers... * What experience do you have regarding performance of wicket applications? We're still in development, but so far performance hasn't been an issue. * Is there a way to cluster wicket applications? Yes. Same way you would cluster any webapp. Wicket also has a number of different clustering strategies available. * Does wicket use any proprietary, non-standard technologies? Wicket core depends on various OSS libraries, all commercial friendly (ASL compatible). * How does wicket care about session hijacking or sql injection? Session hijacking - not an expert on this, but if I understand correctly, this is mostly a JavaScript concern, so just be careful when you write/use Javascript components. SQL Injection - In general, Wicket's architecture makes it harder for these kinds of attacks because state is kept on the server side (as opposed to URL parameters). That being said, this really has more to do with the persistence layer that you use. So long as you shy away from assembling your own SQL query strings you should be OK. * Is there an easy way to implement SSO? Internal SSO between webapps is possible via the Servlet container, provided all webapps run in the same container. If that doesn't apply to you, you should be able to write a custom authorization strategy for Wicket. * Can I integrate wicket applications into any content management system? Depends on what you want to do here. That being said, there are several native Wicket CMS systems under development. René Samselnig wrote: Hi people, currently I'm evaluating wicket as the future framework in our company. I already found a lot of information but still there is some missing. I hope you can help me out answering these questions. * What experience do you have regarding performance of wicket applications? * Is there a way to cluster wicket applications? * Does wicket use any proprietary, non-standard technologies? * How does wicket care about session hijacking or sql injection? * Is there an easy way to implement SSO? * Can I integrate wicket applications into any content management system? If you have an answer to any of these questions don't hesitate to ignore the others - any input is welcome! Thanks in advance, René -- View this message in context: http://www.nabble.com/Evaluating-Wicket-tp15306535p15309004.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Presented Wicket to my Company...
Just to add a few things to this list. I took a good look at JSF/Seam/EJB3/JPA stack about a year ago. - People say JSF has a rich ecosystem (Trinidad, ICEFaces, MyFaces, SEAM, Facelets, etc.) but the downside to that is that you won't have one forum to go to in order to get framework help. Contrast that with this mailing list, which according to Nabble is the 3rd most active Java Software mailing list (next to Netbeans.org and Java.net). - The JSF processing lifecycle is an ugly beast. Worse, you have to know the lifecycle if you're building something stateful (SEAM-managed conversations). Try building a wizard pattern with forward/back and validations using SEAM/JSF, you'll see what I mean. - You'll want to use SEAM if you go with JSF, and you'll want EJB3 if you want to go with SEAM. Out-of-container testing and hot-deploys are not easy with EJB3, and this will significantly slow your code/debug cycle. - You'll also have a hard time using Maven (which is great once you get it going) if you go with Seam/EJB3. - Anything that is standards based has the drawback of slow progress, and will be roughly 1.5 years behind the state-of-the-art. (Compare JPA vs Hibernate.) - If adhering to standards is a core argument for using JSF, ask yourself, after using non-standard add-ons (widget libraries, Facelets, SEAM) if you're truly adhering to standards at that point... - Anyway, Struts is the de-facto standard for web development, not JSF or anything else by a long shot. David Bernard-2 wrote: Short version of my experience, last year I created a project with Seam+Facelets+JSF+EJB3/JPA+jBPM. I was optimist JSF is a standard with 2+ years old, lot of providers,... * JSF : I tried to mixed components from several provider, Trinidad, ADT, MyFaces, Ajax4JSF,... it was a nightweird and time lost (lost of incompatibility in the configuration, rendering,...) * JSF : I try to create my own components (and read Pro JSF and Ajax: Building Rich Internet Components), very complex : Request lifec cycle, extensions points, lot of xml to write and keep sync * JSF : sometime nothing appends due to exception or reject in the dark zone of the request life cycle, so don't forget to display messages on every page * JSF : some basic widget (select) always need hack to work * JSF : create nasty/crapy html, with lot of form, javascript, div : difficult to debug * Seam : lot of good idea, need to understand Injection and Outjection, need to be carefull of scope (request, conversation, session, application) of In/outjection * Seam : some features didn't work with third party JSF components * Seam : required EJB * Facelets : nice, helping information on failure, templating, tools/facilities to create simples components * jBPM : nice GUI to design workflow and pageflow = lot of getter/setter, lot of xml, not easy to test/mock * documenation : too many source After 3 month, I switch to : * Spring instead of Seam + full EJB3 * hand code instead of jBPM * session instead conversation scope (spring doesn't support conversation/continuation natively) And keep JSF(Facelets+Ajax4JSF+MyFaces), JPA(Hibernate). About Spring + JSF, you had 2 choice * every Bean (from spring) could be accessed from a JSF page * only bean declared into an xml file could be accessed About html preview : * facelet allow to use regular html tag with attribute like wicket, but it's an option, and lot of components need to have child component with special tagname and every/lot of component add tag when it's rendering (runtime) = css from static page template need to be changed. * facelet like wicket allosw to define fragment, displaying page with fragment or fragment alone isn't very usefull. (note : I use fragment as general term, not in the Wicket terminology) Result : I was pretty happy with the final solution but lot of xml to maintain. It's quicker to start wth JSF than Wicket, but when to start to customize and use none basic widget,... welcome to hell (of configuration, documentation,...) WARN: it's a 2006 experience. I've not used JSF extension/preview from IDE /david robert.mcguinness wrote: ...to tell you the truth, it impressed the developers but I didn't get that feeling from the top brass. I am pretty sure we will move towards Seam/JSF/Facelets (we have a presentation on that tech next week given by another developer) since it is standard. Has anyone here worked with the Seam tech? All the examples I have seen (including Facelets) is nothing but tag soup with scriptlets in the page (albeit small). The configuration for a Seam project seems like a pain and was also told that the JSF/Seam/Faclets jsp pages can be previewed in a browser (something I thought was so clever about Wicket html pages...and I was under the impression that Wicket was the only tech that allowed true separation of concerns; allowing the web designer to work independenly of the programmer with no
Re: Wicket Employers page on the wiki
lt;plug shameless=truegt;Added my company to the list.lt;/pluggt; On 9/18/07, Matej Knopp [EMAIL PROTECTED] wrote: Sounds like a good idea to me. -Matej On 9/18/07, Scott Swank [EMAIL PROTECTED] wrote: Would it be appropriate to add a Companies Hiring Wicket Developers page? :) - Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/%22Wicket-Employers%22-page-on-the-wiki-tf4477163.html#a12768313 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AjaxFallbackDefaultDataTable... changing sort does not setCurrentPage to 0
I noticed this in the examples:
http://www.wicket-library.com/wicket-examples/repeater/?wicket:bookmarkablePage=%3Aorg.apache.wicket.examples.repeater.AjaxDataTablePage
Changing the sort order does not seem to take you to the first page... I
stepped through the code, and it looks like it should work. Any ideas on how
to get this to work? Here's the relevant snippet from HeadersToolbar:
protected WebMarkupContainer newSortableHeader(String headerId, String
property,
ISortStateLocator locator)
{
return new OrderByBorder(headerId, property, locator)
{
private static final long serialVersionUID = 1L;
protected void onSortChanged()
{
getTable().setCurrentPage(0);
}
};
}
--
View this message in context:
http://www.nabble.com/AjaxFallbackDefaultDataTable...-changing-sort-does-not-setCurrentPage-to-0-tf4325258.html#a12318280
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AjaxFallbackDefaultDataTable... changing sort does not setCurrentPage to 0
I'm not that intrepid so I think I'll just wait until beta3 to get those fixes. The extensions AjaxFallbackDefaultDataTable and related classes are extremely nice, btw. It's allowed me to quickly set up list paging and sorting in a way that would have taken me days using any other web framework. I do have some requests for refinement: 1. It'd be nice to have hard (not runtime generated) CSS classes or ids on HTML elements for components like the NavigatorToolbar, etc. to allow for easy styling via CSS. Something similar to the OddEvenItem concept applied to the page links in the toolbar. I've found a way to style those links, but it could be made easier. 2. Some way to hard-set the width for each column. It's visually distracting to have the column widths change as you page through. This might be done via CSS (maybe give each column a class or id) but this could also be done in Java, for example: ListIColumn columns = new ArrayListIColumn (); columns.add (new SizedPropertyColumn (new Model (ID), id, id, 20%)) ; columns.add (new SizedPropertyColumn (new Model (First Name), firstName, firstName, 40%)) ; columns.add (new SizedPropertyColumn (new Model (Last Name), lastName, lastName, 40%)) ; I'm still a newb, so I'm not sure which way is the wicket way... Thanks, - P igor.vaynberg wrote: i think it has been fixed since then. at least snapshots at wicketstuff.org/wicket13 appear to be working fine. -igor On 8/24/07, Patrick Angeles [EMAIL PROTECTED] wrote: 1.3-beta2 igor.vaynberg wrote: i believe this was fixed a long time ago, what version are you seeing this with? -igor On 8/24/07, Patrick Angeles [EMAIL PROTECTED] wrote: That was fast :) Also, while we're on it, I just noticed that the NavigationToolbar text is off. For a list of 50 items with a pagesize of 5, it says: Showing 1 to 6 of 50 (should say Showing 1 to 5 of 50). -- View this message in context: http://www.nabble.com/AjaxFallbackDefaultDataTable...-changing-sort-does-not-setCurrentPage-to-0-tf4325258.html#a12320251 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/AjaxFallbackDefaultDataTable...-changing-sort-does-not-setCurrentPage-to-0-tf4325258.html#a12320800 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/AjaxFallbackDefaultDataTable...-changing-sort-does-not-setCurrentPage-to-0-tf4325258.html#a12321602 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Callbacks triggered by keyboard...
Is this possible in Wicket, say for example, as a way to scroll down a listing, or go left and right on a menu? Thanks in advance... -- View this message in context: http://www.nabble.com/Callbacks-triggered-by-keyboard...-tf4227815.html#a12027815 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
