Re: Best Wicket Books or Tutorials
On Mon, Mar 31, 2008 at 7:45 AM, Gareth Segree <[EMAIL PROTECTED]> wrote: > Is "Enjoying Web Development with Wicket" any good? Easiest way to start reading yourself, as you can download the first three chapters for free. And the first chapter of both Wicket In Action and Pro Wicket are freely downloadable as well. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use an action level authorization?
>My question is simple... :) How to use an action level > authorization. I cannot find any info or example. There is an example of it in wicket-examples that uses wicket-auth (which in itself is mainly an example project). Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: "Wicket in Action" (Amazon & MEAP)
Hi, This is something for Manning to answer, as they are in charge of all the commercial aspects of it. Cheers, Eelco On Tue, Apr 22, 2008 at 6:04 AM, Alex Objelean <[EMAIL PROTECTED]> wrote: > > This question is for the Wicket in Action authors. > The company I'm working for have ordered the paperback from Amazon. Now, I > would like also to have access to MEAP. What should I do? > -- > View this message in context: > http://www.nabble.com/%22Wicket-in-Action%22-%28Amazon---MEAP%29-tp16824089p16824089.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]
Re: VOTE: Generics of IDataProvider
I would have a better idea if I would have had the chance to actually play with it, but here is mine: [ ] IDataProvider [ x ] Iterator> , drop model [ ] Leave as is. Looks most elegant to me, and it is immediately clear what T is for. Also, I think that generics are bloody verbose anyway, so I'm not much in favor of shortening things up - and not support some of the use cases - for just this occasion. I rather have something that works for everyone. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket 2.0 time frame
Hi, See reaction inline. > Stateless Sites > - > > For example, Google's search is apparently stateless. I can bookmark any > search result, go away for hours, days or weeks and re-visit the link > without experiencing a session-expired message. I shop at Amazon quite a > bit. I can have a page open to a product for hours and no matter when I > click "buy now", it always works. My Yahoo page is similar. I use several > computers and I may have a My Yahoo page open from days ago. If I click on > any link, or submit a form (e.g., weather / stock), it always works. So, in > many common sites, they appear to be stateless. Some of these cites > certainly maintain some state on the back-end, but it is transparent to the > user. Such sites are often relatively simple UI-wise, and bookmarkability and indexing for searching are important considerations (like you stated). Wicket might be not the best choice for these kinds of sites. If you use WIcket for them, you have to plan well, using bookmarkable pages/ links and other Wicket tricks. Amongst Wicket's strong points is that it scales very well for development (due to the fact that you can develop self contained components and use static typing for instance), and that it makes developing complex UIs relatively easy. If you don't have to deal with complex UIs/ large diverse teams etc/ Wicket might actually be overkill and even in your way. Do note however, that you would likely replace one hassle (in your case planning for bookmarkability/ session continuation) with others when using other frameworks (like security concerns for instance). > Examples of sites which are legitimately stateful and require you to start > over when the session expires are banking and finance sites. If you leave a > page open for a while and go back to click on a link, you often get "your > login timed out" and you have to login again and start over. Yeah, such are the sites that I typically had to develop (and still) during my career. Rather than focussing on whether sessions should be resumed automatically etc, often a more interesting question is how complex your UI is. Search and e-commerce sites are fairly simple UI wise. Things get more interesting - and often very difficult to implement elegantly with other frameworks - when you incorporate tabs, wizards, pageable lists etc. > Some of them > remember where you wanted to go and redirect after you re-login. That's easy to achieve with Wicket. > Wicket > > > My experience comes from moving http://online.ddpoker.com/ from jsp to > wicket. I'm about 75% done. Other than normal learning curve time, it > feels like I've been spending too much time fighting the session expiration > consequences. My goal (as is most, I would guess) is to create a site that > has a good user experience. I don't want a user to ever see a "page expired > message". That is bad application design. I want my architecture to help > me avoid bad design. > > One example was figuring out how to create a bookmarkable form submission (I > captured my experience on my wiki: http://tinyurl.com/6xhyl3 ). > > Another example is trying to get my login form to not expire. However, > since I unveil it via Ajax, it seems to not want to be stateless ... haven't > investigated it much, but I'll probably have to create some workaround. Yeah, our Ajax implementation is in the way of statelessness. You could develop something from scratch, where the Ajax part is not based on behaviors. > My point is that wicket should make things easier. These seem like very > common issues - I'm curious to hear other users perspectives and > experiences. I would be in favor of having stateless Ajax somehow, at some point. Not easy though. Wicket is already 10 times more complex than most of us would like, and facilitating more corner cases (which I mean respectfully btw) will make it even more complex. > If I were on the wicket team, I'd ask the question: How could one use > Wicket to rebuild sites like Google, Amazon.com, My Yahoo, etc.? > Developers are looking to choose a framework to build cool applications. > There are a lot of choices out there. But here is the thing... Most competing frameworks will work OK for building sites like Google and Amazon etc. Is brilliant as some of these implementations are I'm sure, the interesting stuff in such sites happens in the back-end, not so much the UI. Before I stumbled on Wicket, I was looking for a framework that would help us scale our development effort, and that would let us develop web *applications* with complex user interfaces without having to resort to a big bag of hacks (typically ad-hoc session usage) and ending up with code that is very hard to maintain. What I'm saying is that Wicket was *not* designed for Google and Amazon like sites. If you browse the archives of this list, and even maybe an interview here and there, you can see that we re
Re: questions about Matt Raible's web framework comparison
On Fri, May 2, 2008 at 6:48 AM, Johan Compagner <[EMAIL PROTECTED]> wrote: > yes but you also can mount 1 package is 1 go. Or use a custom encoding strategy. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WicketStuff.org Is Down
On Fri, May 2, 2008 at 1:10 PM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > On 5/2/08, Andrew Broderick <[EMAIL PROTECTED]> wrote: > > Also see http://www.wicket-library.com/wicket-examples/ > > Please don't. These examples are *OLD* and not maintained much. We > have been telling folks to not look at those examples for over a year. > Wicket stuff is the place to look for the examples. For > debugging/learning/running corporate demos you really should download > the examples and run them locally. How about taking that site down? I thought that was the plan quite some time ago? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: South African Wicket Users?
> I was wondering if you know of any companies in the Netherlands that do > Wicket web development? > I am looking to immigrate to the Netherlands Try out for a year first and see whether you can cope with the weather and small housing ;-) > and it would be great if I > could continue to work in an > environment where Wicket is being used :) Plenty of such companies around in the Netherlands it seems. Search through the list archives for ideas :-) Topicus, Xebia, Servoy, Hippo, Finalist to name a few. Good knowledge of Dutch is probably required, especially if you want to work outside of 'de randstad'. Good luck, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advisory question
> My web app background is from page oriented frameworks, and now while > using wicket, I find myself creating pages over and over. > I think I can miss many of them, because most of the time all I do is > adding an intelligent reusable component to it. I'm mostly using panels/ go for the smallest granularity I can get. We only really have a couple of pages, most of the navigation is done via replacing panels. Working like that takes a bit to get used to, but is great for avoiding code duplication. A page oriented approach is preferable for when you want pages to be bookmarkable or to be indexed by search engines. You can still do a lot with panels if you encode some logic in your URLs, but simply using pages might be a better idea. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation: Wicket does the right thing? Or right tool?
> 1. It is too much coding. Anybody used Valang in > Spring Module? By using Valang, the validation code is > much clean and a lot fewer and you dont need to create > a class simply for this simple validation. The example you quoted is an example of a reusable validator that checks the values of two components with each other. It's probably a rare case to create a reusable validator for it, as you can achieve the same thing with fewer lines of code by just performing the check on your form's or button's submit method and then setting the error on failure. But the choice is yours whether you want the validation to be reusable (which also means it will be easier to move around in your code) or whether you just implemented quick and dirty (like I often do). Btw, team members, this comment can be found in IFormValidator: * TODO post 1.3: remove validate(form) *make IFormValidator extends IValidator where IValidatable's * value is form.modelobject and error reports on form - that way IBehaviorProvider can extend * IValidator > 2. Valang covers both client AND server-side > validation. Please note that client-side validation is > equally important as server-side's. I feel it is a > must for web apps in terms of user experience. It is very important that the server-side validation is robust, since the client-side can be messed with. Whether client-side validation is important depends... I typically use Ajax if I want checking on the fly. Very easy to implement using Wicket. But if you want client-side validation, you can create a combined validator and behavior (that would contribute the JavaScript code to the client), e.g. by letting your validator implement IValidatorAddListener and adding the behavior (possibly itself) to the component in the onAdded method. Would be fun if someone would pick this up and extend some of the simple validators we have with this. > 3. In Valang + Spring MVD, you have all the validation > code for a form in one place in stark contrast to > spreading it in "controller" code as in Wicket and > mixing validation code with visual manipulation code. > Valang's way is much easier to understand and > management. I don't know Valang, so I'm not sure what you mean. Anyway, you have plenty of choices to hide validation code if it bothers you. Examples are the automatic assignment of validators based on Hibernate annotations like we're doing in the project I work on (done via IComponentOnBeforeRenderListener), or custom components that assign validators to self in their constructors. Personally, I think Wicket's solution to validating components is quite nice as long as the validation is related to one component. If not (multiple components are non-related), it gets more messy, but I can't imagine that would be much better in other frameworks. > So in terms of elegance, productivity, management, > ..., I am not sure Wicket's is right. I think it is if you use your creativity and OO skills to make it fit your style. > Can Wicket provide a better solution? > > I would like to share my concern regarding the > Wicket's WebPage, where you put a form's code for some > visual aspects, validation, ajax, etc. in one place. A > big object. I feel it is too ambitious and it looks > like spaghetti code and mixes concerns/modules in one > place. Comment? Much to debate here, and there are plenty of discussions of the pros and cons to be found on the internet. You don't have to put everything in place; again use your OO skills to make it more elegant. Furthermore, the fact that so much is statically typed Java code that is also stateful makes that it is easy to maintain/ refactor/ navigate/ explore/ debug compared to declarative frameworks. Declarative frameworks often can result in less code, but typically only for relatively simple things, and you won't get any of the advantages of working with statically typed code. Also, a declarative framework - a DSL in fact - can never be as flexible as a general-purpose language. Wicket is very flexible because of that. Whether limitations of declarative frameworks hit you of course depends on what you're doing with it. Good luck, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation: Wicket does the right thing? Or right tool?
> Thanks so much for your input! I am still seriously > learning Wicket now and will see if I will change my > mind. > > BTW, what is the best Wicket example website? Best to download the Wicket examples distribution or check out from our subversion repo, so that you can browse through the source. And don't forget to search through this mailing list (archives) and look at the WIKI if you're stuck with something. > I often have many questions when reading tutorials with simple > examples. I wonder Wicket can do or how do more > callenging/complex situations that I can easily handle > with Spring MVC. You bet! There may be cases where using Wicket is overkill, but it certainly beats the hell out of competitors when it comes to handling complex cases. :-) You could download the first chapter of Wicket In Action (http://www.manning.com/dashorst/) to get our take on what exactly we're trying to solve (and what isn't solved by model 2 frameworks like SpringMVC and Struts etc) Cheers, Eelco Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LogoutPage - Responsible for invalidation and redirection to non-wicket page
> So you are saying re-direction isn't supported in the constructor ? It should be supported. But throwing an abort exception is better, if only because whatever else you're doing in your constructor will be skipped. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there a setGatherAbbreviatedBrowserInfo(true) as appose to setGatherExtendedBrowserInfo(true)?
On Fri, May 2, 2008 at 4:59 PM, Matthew Young <[EMAIL PROTECTED]> wrote:
> I only want to find out the user's timezone.
> setGatherExtendedBrowserInfo(true) redirect page take too long, sometimes
it
> stays on the screen many seconds.
You can often best do this in a custom way by either creating your own
variant of WebRequestCycle#newClientInfo or e.g. by integrating it in a
login form for instance (which of course only works for applications where
users have to be logged in before they get to the point where your browser
info matters).
That roughly works like this:
Java:
pubic LoginForm(String id) {
super(id, new CompoundPropertyModel(new ClientPropertiesBean()));
add(new HiddenField("navigatorAppName"));
add(new HiddenField("navigatorAppVersion"));
add(new HiddenField("navigatorAppCodeName"));
add(new HiddenField("navigatorCookieEnabled"));
add(new HiddenField("navigatorJavaEnabled"));
add(new HiddenField("navigatorLanguage"));
add(new HiddenField("navigatorPlatform"));
add(new HiddenField("navigatorUserAgent"));
add(new HiddenField("screenWidth"));
add(new HiddenField("screenHeight"));
add(new HiddenField("screenColorDepth"));
add(new HiddenField("utcOffset"));
...
HTML template:
...
...
...
Login.js:
function submitform(form) {
form.navigatorAppName.value = window.navigator.appName;
form.navigatorAppVersion.value = window.navigator.appVersion;
form.navigatorAppCodeName.value = window.navigator.appCodeName;
var cookieEnabled = (window.navigator.cookieEnabled)? true : false;
if (typeof window.navigator.cookieEnabled == "undefined" && !cookieEnabled)
{
document.cookie = "wickettestcookie";
cookieEnabled = (document.cookie.indexOf("wickettestcookie")!=-1)? true :
false;
}
form.navigatorCookieEnabled.value = cookieEnabled;
form.navigatorJavaEnabled.value = window.navigator.javaEnabled();
form.navigatorLanguage.value = window.navigator.language ?
window.navigator.language : window.navigator.userLanguage;
form.navigatorPlatform.value = window.navigator.platform;
form.navigatorUserAgent.value = window.navigator.userAgent;
if (window.screen) {
form.screenWidth.value = window.screen.width;
form.screenHeight.value = window.screen.height;
form.screenColorDepth.value = window.screen.colorDepth;
}
form.utcOffset.value = (new Date().getTimezoneOffset() / -60);
return true;
}
That should give you an idea :-)
Eelco
Re: How to avoid Lazy loading exception
Fwiw Mathias, here is a model class that I like to use in the project I work
on:
/**
* LDM for domain objects. Detaches (nulls) object after each request.
*/
public class DomainObjectModel
extendsLoadableDetachableModel {
@SpringBean
private GenericHibernateDao dao;
private final Class domainClass;
private final Long id;
/**
* Construct with class and id; next invocation will trigger loading the
* object with the id.
*
* @param domainClass
* @param id
*/
public DomainObjectModel(Class domainClass, Long id) {
if (domainClass == null) {
throw new IllegalArgumentException("domainClass may not be null");
}
if (id == null) {
throw new IllegalArgumentException("id may not be null");
}
SpringInjector.injectDependencies(this);
this.domainClass = domainClass;
this.id = id;
}
/**
* Construct with domain object instance, which will be reused for the
* current request.
*
* @param domainObject
*/
@SuppressWarnings("unchecked")
public DomainObjectModel(T domainObject) {
super(domainObject);
if (domainObject == null) {
throw new IllegalArgumentException("domainObject may not be null");
}
SpringInjector.injectDependencies(this);
this.domainClass = (Class)
HibernateProxyHelper.getClassWithoutInitializingProxy(domainObject);
this.id = domainObject.getId();
}
@Override
public boolean equals(Object obj) {
return Objects.equal(obj, getObject());
}
@Override
public int hashCode() {
return Objects.hashCode(getObject());
}
/**
* @see org.apache.wicket.model.LoadableDetachableModel#load()
*/
@Override
protected Object load() {
return dao.load(domainClass, id);
}
@SuppressWarnings("unchecked")
@Override
public T getObject() {
return (T) super.getObject();
}
}
Where DomainObject is:
/**
* Should be implemented by all normal domain objects.
*/
public interface DomainObject extends Serializable {
/**
* @return The id of the domain object
*/
Long getId();
}
Might not be what you want, but it is probably a good idea to make such a
model class that you can reuse throughout your project(s).
Probably also can be improved with Wicket 1.4, but I didn't get to look at
that yet :-)
Eelco
On Sun, May 4, 2008 at 10:11 AM, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
> you still have something misconfigured or you are not using detachable
> models where you should. ive built plenty of hibernate+spring+wicket
> apps to know that it works just fine and is pretty easy to do. if you
> want you can post a quickstart that demonstrates your problem and
> someone might be able to help you.
>
> -igor
>
>
> On Sun, May 4, 2008 at 10:01 AM, Mathias P.W Nilsson
> <[EMAIL PROTECTED]> wrote:
> >
> > I have session in view filter but still gets LazyLoadingException even
> if I
> > use detached models! Ahhh...
> >
> > Solved it temporarily by using Eager fetch but this is going to end up
> bad
> > if everything is eager.
> > --
> > View this message in context:
> http://www.nabble.com/How-to-avoid-Lazy-loading-exception-tp17040941p17048739.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]
>
>
Re: How to lookup Page or Class from a URI path ?
> Because I need the Class so i can check for the presence of an annotation > (@InternalPage). If that annotation is present, only internal requests from > 10.x.x.x are allowed. Otherwise a 403 (Forbidden) will be generated. > > Obviously i can control access with Apache, or a ServletFilter..heck for > that matter in the Page constructor itself. I feel the better solution is > with my annotation and before the Page constructor is called. How about using an authorization strategy? If I understand you correctly, that's written exactly for the stuff you're trying to do here. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: way to traverse / get all form validators
On Fri, May 2, 2008 at 11:56 AM, Gerolf Seitz <[EMAIL PROTECTED]> wrote:
> there is
> final List getValidators() {...} on FormComponent
which you can use like this:
Use a visitor, like:
visitChildren(FormComponent.class, new IVisitor() {
public Object component(final Component c) {
FormComponent fc = (FormComponent)c;
List validators = c.getValidators();
...
}
}
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation: Wicket does the right thing? Or right tool?
> How is your Wicket in Action? Download the first chapter and see for yourself :-) It's free after all, and no registration required (I think). Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invoulentary session sharing/leakage in Wicket 1.3.x
On Mon, May 5, 2008 at 8:20 AM, Iman Rahmatizadeh <[EMAIL PROTECTED]> wrote: > I'm also experiencing this with jetty. Is everybody else the same ? It would be great if we would have this reproducible as a test case or something. I created wicket-threadtest in the past because we needed to reproduce similar problems. If someone would pick up writing a similar test (or even a patch on wicket-threadtest), we'd be more certain that once we found the problem we fix it properly. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: way to traverse / get all form validators
Good point. Looks to me like it is something we overlooked. We should probably add a method to get the form validators of a form. Could you open an RFE for that please? Eelco On Mon, May 5, 2008 at 2:31 AM, michalb_cz <[EMAIL PROTECTED]> wrote: > > thank you for response, but I need it for Form object - to get all > IFormValidator objects associated with the Form object - through > form.add(IFormValidator) > -- > View this message in context: > http://www.nabble.com/way-to-traverse---get-all-form-validators-tp17020385p17054006.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]
Re: converter can not convert org.myproject.Something to a string
On Mon, May 5, 2008 at 5:56 AM, Johan Compagner <[EMAIL PROTECTED]> wrote: > that is a wrong check yes > its removed. JIRA? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: London Wicket Event - June 4th, at Google UK
> I'm pleased to confirm that our next London Wicket Event will be held on June > 4th, again at Google's London offices. And again it is very nice of you guys to organize this, and of Google to host. Thanks! Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comet and Wicket
> Hello, > I deploy the wicket-push example on tomcat latest version and it > worked...and also i will test in JBoss 4.2.x...hoping to work as well bcoz > JBoss use tomcat container...anyway, you can embed jetty container in JBoss > too :) Actually, for all I know JBoss doesn't provide it's own servlet container and thus requires Jetty or Tomcat (which is the default?) to do the servlet work. So it's not really embedding :-) I don't know whether work on Tomcat for wicket-push was done or even considered. The problem is that Comet is not standardized, so we have to implement a specific solution for every servlet container we want to support. Help with that is more than welcome of course. Maybe you could drop a line here: http://www.theserverside.com/news/thread.tss?thread_id=49212 or on somewhere else with similar discussions. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comet and Wicket
On Mon, May 5, 2008 at 11:47 PM, Johan Compagner <[EMAIL PROTECTED]> wrote: > They are busy making it a standaard in the next servlet spec Let's hope they can agree on how to do that. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Private Homepage Redirection
> I tried both AbortException and RestartResponseException. They didn't work. > AbortException basically causes Wicket to show a blank page instead of > redirecting to the external site while RestartResponseException caused stack > overflow error. The exceptions were thrown in > onUnauthorizedInstantiation(...) method. You should use the RestartResponseException, not AbortException directly. The stack overflow error is something you can fix yourself; make sure you redirect to a page that won't cause these redirects to be triggered again. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comet and Wicket
> Hello eelco, > Anyway JBoss default servlet container is tomcat, but they are replacing it > with their own container which is jboss-web i dont know if they already > did... Ah, I didn't know that. > anyway, im experementing on wicket-push bcoz the cleint wants some > sort of messaging on their app..(actually our web-app is entirely made on > wicket :) so im here )...but my problem is how to send specific message > notification to a person logged in...any idea how to accomplish this would > be great... Note that you can still implement messaging the 'old fashioned' way by using Ajax polling (basically a thread in your browser that polls for new events every n seconds). But ideally, we have implementations of wicket-push for every project. I don't know enough about that project to see anything beyond that though... > anyway, i have a copy of wicket-in-action it is great i learn a > lot from that. Good to hear :-) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] wicketstuff-annotation 1.0 released
Nice job! Great that you added a WIKI page and a proper build config etc.
Cheers,
Eelco
On Tue, May 6, 2008 at 12:33 PM, Doug Donohoe <[EMAIL PROTECTED]> wrote:
>
> I am pleased to announce the 1.0 release of wicketstuff-annotation.
>
> Full documentation and explanation (e.g., what, why, how) is at the
> wicket-stuff wiki:
>
> http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-annotation
>
> A short example is at the end of this email.
>
> I would like to thank Mr Mean and Martijn Dashorst for their assistance in
> getting this project in TeamCity. The process was fairly painless thanks to
> their work.
>
> Our pom.xml is pretty simple, is configured to generate javadoc and depends
> on wicketstuff-parent. It should be a good example for other wicket-stuff
> projects (if they need one).
>
> Thanks,
>
> -Doug Donohoe
>
> Use wicketstuff-annotation to use Java Annotations and class path searching
> to mount your Wicket pages:
>
>
> @MountPath(path = "terms")
> public class Terms extends WebPage { ... }
>
> @MountPath(path = "terms")
> @MountMixedParam(parameterNames={"sport", "show"})
> public class Dogs extends WebPage { ... }
>
> public class MyWicketApplication extends WebApplication
> {
> @Override
> protected void init()
> {
> new
> AnnotatedMountScanner().scanPackage("com.acme.wicket.pages").mount(this);
> }
> }
>
> --
> View this message in context:
> http://www.nabble.com/-announce--wicketstuff-annotation-1.0-released-tp17090601p17090601.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]
Re: [announce] wicketstuff-annotation 1.0 released
On Tue, May 6, 2008 at 2:24 PM, Hoover, William <[EMAIL PROTECTED]> wrote: > Would it be better if there were a core wicket-annotation project that > provides the basics (such as the scanner) and another project called > wicket-automount (with wicket-annotation dependency)? That way other > "future" projects can utilize the core capabilities without reinventing > the wheel. This would also accommodate those who want a specific > dependency for wicket-automount. The project can be split without needing to make one a core project though. On the long term we could consider making something like that a core project, but for now that simply wouldn't be practical. The great thing about wicket-stuff projects is that it is easy for people to join the effort. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to generate 403 Forbidden?
> and we have 2: > AbortWithWebErrorCodeException Uses HttpServletResponse#sendError > AbortWithHttpStatusException Uses HttpServletResponse#setStatus > why 2? i dont know i think we need to clean up here (eelco? igor? who > was first ;) ) >From HttpServletResponse#setStatus: * Sets the status code for this response. This method is used to * set the return status code when there is no error (for example, * for the status codes SC_OK or SC_MOVED_TEMPORARILY). If there * is an error, and the caller wishes to invoke an error-page defined * in the web application, the sendError method should be used * instead. * The container clears the buffer and sets the Location header, preserving * cookies and other headers. >From HttpServletResponse#sendError: * Sends an error response to the client using the specified * status. The server defaults to creating the * response to look like an HTML-formatted server error page * containing the specified message, setting the content type * to "text/html", leaving cookies and other headers unmodified. * * If an error-page declaration has been made for the web application * corresponding to the status code passed in, it will be served back in * preference to the suggested msg parameter. * * If the response has already been committed, this method throws * an IllegalStateException. * After using this method, the response should be considered * to be committed and should not be written to. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] wicketstuff-annotation 1.0 released
On Wed, May 7, 2008 at 12:20 AM, Johan Compagner <[EMAIL PROTECTED]> wrote: > if the scanning of the classpath is expensive (i guess all classes are > loaded that are scanned..) > cant there be an option that the scanning is only done once? > When you create the jar so with maven/ant? > When creating the jar you are scanning everything and create a manifest > entries of all the packages. > those manifest entries are then read in when the jar is in the classpath So it would be either you find a special entry and use that or you scan if such an entry is not found for a jar? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] wicketstuff-annotation 1.0 released
> > if the scanning of the classpath is expensive (i guess all classes are > > loaded that are scanned..) > > It says: "Note that Spring does not load the class to determine this > information. Instead, it uses a meta-data reader to determine this (which is > faster than going through class loading)." and also: "The class path > scanning is very efficient by itself and limiting the search only makes it > faster." Deep down it does scan the class path though, in a very similar way as we do in some parts of Wicket. I don't know much about ASM (which is used by Spring to visit the class definitions). Is that where you get the edge in performance? Anyway, I'm not sure whether you actually need Spring (and) ASM to do the trick, but it does look quite nice, both the Spring code and how wicketstff-annotation does it. Cheers, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] wicketstuff-annotation 1.0 released
> In my project, I have 60+ jar files in the classpath and the scan only took > 255 milliseconds (on a 1.66 ghz core duo mac). Yeah, that sounds perfectly acceptable. > Also note that anything JAR-based > would not easily work in development environments where you don't JAR after > each change. Yeah, I agree it is probably asking for trouble. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PageParameters request-for-enhancement
Hi,
You can best file an RFE in JIRA for things like this. The list is
primarily for questions and discussions, and adding it to JIRA will at
least make sure it stays on the list of things to look at.
Cheers,
Eelco
On Thu, Apr 24, 2008 at 3:00 PM, Doug Donohoe <[EMAIL PROTECTED]> wrote:
>
> Hi Wicket team:
>
> I'd like to be able to call getInt(name, default) and not have to worry
> about catching exceptions. If the number can't be parsed, just return the
> default.
>
> I have a utility method which I use:
>
> public static int getInt(PageParameters params, String name, int def)
> {
> try
> {
> return params.getInt(name, def);
> }
> catch (StringValueConversionException ignored)
> {
> return def;
> }
> }
>
> Basically for my bookmarkable pages, I don't care if a user mucks with the
> URL - this would let me default to something reasonable.
>
> It would be nice if there were a comparable method on PageParameters ...
> like getIntSafe(name, def) or some something similar (and for other
> number-based getters).
>
> In addition, it would be nice to have a getInteger() object method that
> returns null if not defined or an Integer object. The way it is now, I have
> to pick a default value that I assume won't ever be valid (usually -1).
> There are valid use cases where null is an expected value.
>
> -Doug
>
> -Doug
>
>
> --
> View this message in context:
> http://www.nabble.com/PageParameters-request-for-enhancement-tp16853545p16853545.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]
Re: Label to Uppercase
> I need your suggestion on, what are the ways I can get Label to print in
> Uppercase.
Several ways. An easy one:
public class UpperCaseLabel extends Label {
public UpperCaseLabel(String id) {
super(id);
}
public UpperCaseLabel(String id, String label) {
super(id, label);
}
public UpperCaseLabel(String id, IModel model) {
super(id, model);
}
@Override
protected void onComponentTagBody(final MarkupStream markupStream,
final ComponentTag openTag) {
String s = getModelObjectAsString();
replaceComponentTagBody(markupStream, openTag, s != null ?
s.toUpperCase() : null);
}
}
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Label to Uppercase
Yeah, that a more generic solution. You can even use converters. If
you want to get into an argument with Igor that is ;-)
Eelco
On Wed, May 7, 2008 at 2:25 PM, Jeremy Thomerson
<[EMAIL PROTECTED]> wrote:
> As Eelco mentioned, there are quite a few ways... I typically use delegation
> for this sort of thing with a model that wraps another model. This way it
> can be reused for a Label, dropdown, textfield, etc
>
> you could do then:
> add(new Label("myLabelID", new UpperCaseModel(new
> PropertyModel(myObject, "myField";
>
> With code like:
>
> import org.apache.wicket.model.IModel;
>
> public class UpperCaseModel implements IModel {
>
> private static final long serialVersionUID = 1L;
>
> private final IModel mNestedModel;
>
> public UpperCaseModel(IModel nestedModel) {
> if (nestedModel == null) {
> throw new IllegalArgumentException("parameter 'nestedModel' can
> not be 'null'.");
> }
> mNestedModel = nestedModel;
> }
>
> public String getObject() {
> String obj = mNestedModel.getObject();
> return obj == null ? obj : obj.toUpperCase();;
> }
>
> public void setObject(String object) {
> mNestedModel.setObject(object);
> }
>
> public void detach() {
> mNestedModel.detach();
> }
>
> }
>
> Hope this helps...
> Jeremy Thomerson
>
> On Wed, May 7, 2008 at 4:06 PM, Eelco Hillenius <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > > I need your suggestion on, what are the ways I can get Label to print
> > in
> > > Uppercase.
> >
> > Several ways. An easy one:
> >
> > public class UpperCaseLabel extends Label {
> >
> >public UpperCaseLabel(String id) {
> >super(id);
> >}
> >
> >public UpperCaseLabel(String id, String label) {
> >super(id, label);
> >}
> >
> >public UpperCaseLabel(String id, IModel model) {
> >super(id, model);
> >}
> >
> >@Override
> >protected void onComponentTagBody(final MarkupStream markupStream,
> > final ComponentTag openTag) {
> >String s = getModelObjectAsString();
> >replaceComponentTagBody(markupStream, openTag, s != null ?
> > s.toUpperCase() : null);
> >}
> > }
> >
> > Eelco
> >
>
>
> > -
> > 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]
Re: Ajax and Loop
> I have a Loop on my page (creates Components from a List ot Objects). > Now I have an AjaxFallbackLink on my page. This link adds an Object to > my List and as a reaction to this action I want my Loop to be repainted > (showing the new object). What must I do? A simple > "target.addComponent(Loop.getParent())" has no effect. > The Components of the loop are created in the Constructor of the Loop's > parent. Do I have to overwrite some "beforeRender" methods? Of course, I > took a look at the Wicket In Action book and the Wiki and the List but I > did not find a hint. Can anybody help me? Repainting the loop won't have an effect because it is still the same instance. If you want to keep using Loop, you'll have to replace it with a new instance so that it will populate it's child components based on the model now. Or use RefreshingView (consider using ReuseIfModelsEqualStrategy if in a form) or ListView with reuseItems == false. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ajax and Loop
> Have you tried using a ListView in combination with a model (rather than > passing a List to the constructor of ListView)? That won't trigger a re-population of the child components (ListItem and everything you add to it). For that, you need to call setReuseItems(false). Note that this can cause problems in forms (particularly with updating feedback), so when using forms, things like RefreshingView are often preferable. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IDataProvider and grouping
On Tue, May 6, 2008 at 10:51 AM, Scott Swank <[EMAIL PROTECTED]> wrote: > Has anyone implemented grouping of items, i.e. sort/group items by > location and thereby add a location-level grouping. I'm considering > implementing this as a Border around groups of items. Basically any > lessons learned would be more than welcome. I regularly do, but need it so specific each time that I never generalized any. And if you don't have to generalize, code can be shorter, especially when working with plenty of inner classes. > If I get anything particularly reusable I'll make it available to > wicket-stuff. I'd be very interested to see such a contribution though. Repeaters are very powerful already, but can definitively be extended with a bunch of interesting use cases. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IDataProvider and grouping
We have a whole bunch of custom components that are somewhat generic. Unfortunately, they'd need a lot of clean up before they could be made available as open source, and here and there they are tied in to our domain model and specific classes for our project etc. One of the components we have is a panel with a search field that acts as a filter and that displays a sortable, pageable results list. Very handy, and I can imagine that most projects can use such a component. In the near term I won't be able to contribute that back though. Cheers, Eelco On Wed, May 7, 2008 at 5:01 PM, Scott Swank <[EMAIL PROTECTED]> wrote: > I have a SortedDataProvider that uses a Comparator to sort the > items. However that requires retrieving all of the items -- which is > perhaps not what an IDataProvider is meant to do. Then I have a > GroupingDataProvider that extends > SortedDataProvider and wraps SortedDataProvider. This is > all pretty straightforward. > > We are re-sorting and re-grouping the data dynamically -- hence the > Comparators instead of pushing the sorting/grouping off to the > database where it really belong, at least from a > performance/scalability perspective. > > Once I have it working in a reaonsably nice way with UI components > I'll send something along. > > Cheers, > Scott > > > > On Wed, May 7, 2008 at 4:18 PM, Eelco Hillenius > <[EMAIL PROTECTED]> wrote: > > On Tue, May 6, 2008 at 10:51 AM, Scott Swank <[EMAIL PROTECTED]> wrote: > > > Has anyone implemented grouping of items, i.e. sort/group items by > > > location and thereby add a location-level grouping. I'm considering > > > implementing this as a Border around groups of items. Basically any > > > lessons learned would be more than welcome. > > > > I regularly do, but need it so specific each time that I never > > generalized any. And if you don't have to generalize, code can be > > shorter, especially when working with plenty of inner classes. > > > > > > > If I get anything particularly reusable I'll make it available to > wicket-stuff. > > > > I'd be very interested to see such a contribution though. Repeaters > > are very powerful already, but can definitively be extended with a > > bunch of interesting use cases. > > > > Eelco > > > > > > - > > 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]
Re: Label to Uppercase
> When we finally get commons-functor generified, I'm going to create an > IModel implementation that takes a UnaryFunction and wraps another > IModel. Sounds cool, looking forward to it. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket javascripts - reloading every one hour
> It is really needed to repeatedly once an hour download these wicket > javascripts ? > These are static wicket javascripts, they are not subject of changes, so > why could they not be cached for longer time, for example - 1 week, or > longer. Yeah, I think that was chosen arbitrarily. > It would be better, if caching time should be configurable from some > application settings. > Could I create requet for improvement, or it is all ok ? I agree. Please add an RFE. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: behavior for onComponentTagBody
On Wed, May 7, 2008 at 8:42 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > doesnt Label do this already? Yeah, I think just using getModelValueAsString would give the same results. Also, Label is the only (or one of the few at most) class(es) where overriding onComponentTagBody makes sense. Why not do your thing in a base class Eyal? Or... make model wrappers, where the sole purpose of your wrapping models is to format the output of your wrapped models. Or... do this using converters. Creating a base class makes sense if you do this with the same kind of components all the time (labels I pressume?). If your components are very different, any of the other options are fine. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: South African Wicket Users?
> Actually, since I changed jobs, Finalist no longer uses Wicket but now > JTeam (www.jteam.nl) does :) Now it's all up to Remco then :-) Good luck with your new job though. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: "unmount" sub url
On Thu, May 8, 2008 at 3:15 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I've got a page mounted on "/path1". >> >> I've got some files in a directory in my webapp root on "/path1/dir" >> >> How can I tell Wicket to give control back to the servlet container for >> dir? Currently (even using QueryStringUrlCodingStrategy) the mount eats >> /path1/dir and doesn't let me access the files there... >> >> Regards, >> Sebastiaan > > I looked at the wicket filter code, and it does not seem that this is > possible at the moment (though I might be missing something). I see at least > two possible ways to add this feature: > > 1) using a special exception (I did not think about the name): > ... > 2) using a special RequestCodingStrategy, i.e. > UnmountedRequestCodingStrategy and tweaking isWicketRequest to return false > if it detects this request coding strategy... > > What do you guys think? Well, my first impulse is to say that mounting was never meant to serve complex cases, and that instead of mounting you'd do best with a custom request coding strategy instead. That said though, I'm not against something like 2 if we have a nice construct for it. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: behavior for onComponentTagBody
> Johan, Eelco, What do you mean by "Converters"? Is there a special class / > interface I'm not aware of? IConverter. See the forminput example of wicket-examples for an idea. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Overriding panel markup: close tag not found for tag
> Instead, I want the MyPage.html to contain the panel markup: In a > similar manner to how the feedbackpanel markup is given in that > example in the book "created the component component structure inside > the page". You should use a Fragment instead of a Panel in that case. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encapsulation, extension and transparent resolvers
> I know transparent resolvers are currently a major issue and can't be > really handled in a proper way due to the hierarchy concept. But if things > can be fixed with a workaround (until a new transparent resolver model is > established) and which has no impact on the overall functionality - why > can't that make it into wicket? The 'We wont support this' dogma isn't > really proper argumentation. Sorry you're feeling frustrated. However, the "we won't support this" is directly related to our limited time. Even workarounds have to be evaluated, and evaluating patched typically takes (me at least) between an hour up to a whole evening. It won't be the first time a workaround opens up a can of worms no-one imagined before implementing it. In fact, as far as *I* am concerned, those resolvers are very workaround-ish, and opened up the door for more requests we didn't intend. In the end, we are the little dictators of our project, and sometimes (unfortunately for you in this case) that means that we just say no to stuff, even if it seems unreasonable. :-) In the end, if you really feel it is important, you can patch a project yourself - which once upon a time wasn't crazy at all -, and you can leave the JIRA issue open in case someone at some point gets inspiration to work on it. Cheers, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA suggestions?
It really depends on your preferences. Either a databinder (using JPA related classes directly in your UI code) or a DAO/ services based approach will work. Eelco On Tue, May 13, 2008 at 8:29 AM, David Nedrow <[EMAIL PROTECTED]> wrote: > I have a data "driver" package built around JPA and an Entity Manager > Factory (javax.persistence.EntityManagerFactory). This is currently used by > a couple of standalone applications and works well. > > What is the best way to leverage this package in the context of a > Wicket-based web application? IE., how best to instantiate the factory (if > necessary) and/or use the DAOs. Should this happen at the wicket application > level, or somehow page/panel-based? > > Thanks for any pointers, > > -David > > - > 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]
Re: A question about IHeaderContributor
I'm not sure, but I think in 1.2 you can only use this interface for behaviors. Am I right Matej/ others? Nate, can you try adding what you want as a behavior to the form? Eelco On Tue, May 13, 2008 at 4:33 PM, nate roe <[EMAIL PROTECTED]> wrote: > I'm using Wicket 1.2. > > I have a Form that implements IHeaderContributor. My intent is to use > renderHead(Response) to write some JavaScript to the response. The Form is > added to the Page. However, renderHead(...) on my Form is never called. > > Am I using this interface incorrectly? > > Thanks, > Nate > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Processing a form before page components are created
> The reason I want to do this is that my pages are stateless, and I want to > process the submitted form before all the components on the page are > initialised, incase I need to load different data models, or redirect the > request to another page, thus saving unnecessary database calls and > component initialisation. > > At the moment what I am doing is processing the form by directly reading > the page parameters in the constructor before I add any components to the > page, and then redirecting the request or initializing the page as > appropriate (bypassing the use of Form.onSubmit). If you make sure your models/ components work lazily you can avoid database calls being done until the components are actually rendered. Rendering is a separate phase executing after component construction and form handling. And you can let your form just populate a simple bean to avoid database access. I wouldn't worry about the creation of a few components, and you can break of any time with a RestartResponseException or set the next page (without breaking off current processing) using setResponsePage. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A question about IHeaderContributor
On Tue, May 13, 2008 at 5:28 PM, nate roe <[EMAIL PROTECTED]> wrote: > I can try that I suppose. > > The Javadoc for 1.2 seems to mention Component quite a lot though: > > http://wicket.sourceforge.net/apidocs/wicket/markup/html/IHeaderContributor.html Right. I guess I just lost track of what was implemented when. If the docs say it and it doesn't work it might be a bug or you might be overlooking something. If you think it is a bug, please open a JIRA issue for it. Though I would think someone would have reported it earlier, so pls make sure you check your code well. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getBodyContainer replacement for appending attributes to body tag
Hi,
That's described in the migration document here:
[quote]
Replacement for getBodyContainer
If you had code like this:
public void renderHead(HtmlHeaderContainer container) {
((WebPage) getPage()).getBodyContainer().addOnLoadModifier("foo();", null);
super.renderHead(container);
}
you should instead let your component implement IHeaderContributor,
and then in the interface method, do:
public void renderHead(IHeaderResponse response) {
response.renderOnLoadJavascript("foo();");
}
[/quote]
Eelco
On Mon, May 12, 2008 at 2:03 PM, TheMayor <[EMAIL PROTECTED]> wrote:
>
> Hi Guys,
>
> Since getBodyContainer is no longer available as of wicket 1.3.x, how can
> you allow inherited page markup to update or contribute to the body tag's
> attributes (other than onLoad and onUnload). We used to rely on
> getBodyContainer().getBodyContainer().
>
> Thanks for the help
>
> -hc
> --
> View this message in context:
> http://www.nabble.com/getBodyContainer-replacement-for-appending-attributes-to-body-tag-tp17189983p17189983.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]
Re: getBodyContainer replacement for appending attributes to body tag
> That's described in the migration document here: I meant: http://cwiki.apache.org/WICKET/migrate-13.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to reset the feedback panel
In 1.3 and up (so this won't work for 1.2): You can use Session.get().getFeedbackMessages().clear() (or call clear using a filter to just clear specific ones). Component specific feedback messages are also temporarily stored in the session, so you'll get those as well. Btw, Session#getFeedbackMessages says "@return unmodifiable list of feedback messages". This is wrong, as it is mutable (and it is actually not a list anymore). Could you please create a JIRA issue to fix the javadoc for 1.3 and 1.4? Cheers, Eelco On Tue, May 13, 2008 at 6:28 PM, Michael Mehrle <[EMAIL PROTECTED]> wrote: > How do I reset the feedback panel from within an event handler? I tried > to set the feedback's model to null, but that throws an error: > > > > org.apache.wicket.WicketRuntimeException: No get method defined for > class: class com.evite.event.model.Event expression: feedback > > at > org.apache.wicket.util.lang.PropertyResolver.getGetAndSetter(PropertyRes > olver.java:433) > > at > org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter(Prope > rtyResolver.java:275) > > at > org.apache.wicket.util.lang.PropertyResolver.getValue(PropertyResolver.j > ava:84) > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Terracotta and PatternValidator
> I have run into the same issue. I solved it with brute force by > writing a regexp to capture all the inner classes from the Pattern > class and inserting them into my terracotta config's dso section. It > is not the most elegant solution but it will get you past this issue. Why not just writing a validator that keeps a reference to the regex string rather than the Pattern, and create the pattern object just when you need it? There is some overhead in that, but it shouldn't be too bad considering that you'll only use a few of those objects a request at most? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FYI: new wicket site
> A new Wicket site is born! It's a Dutch site on which you can search for day > trips and such. See: www.eropuit.nl. Nice. I like the 'history of Ajax' event. So soon ;-) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A question about IHeaderContributor
>> If you think it is a bug, please open a JIRA >> issue for it. > > > didn't we EOL Wicket 1.2.x? > http://martijndashorst.com/blog/2008/03/23/wicket-127-the-last-maintenance-release/ Yeah, I actually meant for Wicket 1.3 and up, because the bug is in there as well. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Processing a form before page components are created
On Wed, May 14, 2008 at 8:21 AM, Joel Halbert <[EMAIL PROTECTED]> wrote: > What about the situation where one of the components on the Page is a > BookmarkeablePageLink and you need to pass it in some PageParameters? In > this case how do you load the page parameters from the model in a lazy > fashion? It doesn't appear to be possible since PageParameters does not > evaluate against a model, thus the values need to be supplied upfront, while > the page is being created... But you don't have to load the page parameters lazily, right? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Processing a form before page components are created
On Wed, May 14, 2008 at 8:24 AM, Joel Halbert <[EMAIL PROTECTED]> wrote:
> unless, i suppose, if you override getPageParameters, something like this:
>
>private void getLinkToUserProfile(final RatingModel r) {
>return new BookmarkablePageLink("username",
> ViewDetails.class) {
>@Override
>public PageParameters getPageParameters() {
>PageParameters pp = new PageParameters();
>pp.put(Params.userId.toString(),
> r.getRating().getUserId());
>return pp;
>}
>
>};
>}
Right, something like that.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using generics with some non-generic classes in Wicket
> the whole generics thing turned out to be > quiet a lot crappier then i thought it would. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using generics with some non-generic classes in Wicket
On Wed, May 14, 2008 at 2:25 PM, Eelco Hillenius <[EMAIL PROTECTED]> wrote: >> the whole generics thing turned out to be >> quiet a lot crappier then i thought it would. > > :-) Generics for models: great. Generics for components: awful. Too bad that stuff is contagious. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Scheduler in wicket
>> I am planning to use quartz, but before starting to integrate it in my >> wicket's app i would like to know if anybody have used it or another >> scheduler with >> wicket. > > we used Quartz, works like a charm. I wonder, though, what it has to do with > Wicket - your scheduling probably (or rather: hopefully) has nothing to do > with the UI layer of your web app, right? +1 on both. Quartz works fine. But any scheduler and Wicket shouldn't bite each other anyway. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page expired using LazyLoadPanel and clustering
> turns out that there are some new images being added to the page, but the > image url had been messed up, specifically, was '', so when the page loads, Ugh, that's still a very tricky error it seems. I thought Igor recently checked something in for that, that at least prints a warning? I can't find it in the code though. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Visibility vs. CSS visibility
> If you wanted to just a cosmetic, DHTM/CSS "display: none" type of > visibility, is there something you can do other than > making a new AttributeModifier (with a custom Visibility Model kind of > thing) or a SimplleAttributeModifier with a CSS > "display:none" String there? Well, if the component isn't visible (I typically override isVisible, because there's typically an algorithm that determines whether the component is visible), no rendering is done at all, which can save things like database roundtrips if that component or it's children use that, and it also often lets you avoid having to do null checks and stuff in your models (e.g. you can depend on a model function only to be executed when another object - the one that determines whether the component is visible - is checked). Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
On Fri, May 16, 2008 at 7:50 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: > Does that mean that under heavy load, hitting the index page for instance, I > can expect clients to block as each request is processed? Yes, requests to pages/ components that belong to the same pagemap in a session are handled synchronously. Images and other resources like javascript and css files are handled asynchronously. Different clients never block each other. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Visibility vs. CSS visibility
On Sat, May 17, 2008 at 5:28 AM, Kirk Israel <[EMAIL PROTECTED]> wrote: > On Sat, May 17, 2008 at 2:46 AM, Johan Compagner <[EMAIL PROTECTED]> wrote: >> Many people expect that is the component is not visible also the >> models and the data ias not called or touched. Because there state >> cant be resolved correctly. > > Still seems a little odd to me. "We're adding a component, but we're > counting on it not to do anything. Because it's not visible. So it's > not really there. But we put it there anyway!" It is a great facility, really. Consider a search field and a panel that displays results. If there is no search given, you want to hide this panel (which probably also has a border and other visual elements that are only relevant when a search is provided) altogether, and since the panel isn't rendered if implement the hiding by overriding isVisible, you don't have to litter the code of that panel with a dozen null checks, because you know it will only be executed when there is a search term. The same thing /could/ be achieved using component replacement, but for cases like this, that would be way less elegant and more work. Whether 'visible' is the best name... I always found this completely natural, but sure there may be terms to would make more sense to others. Too late for that now, since it's been in Wicket like this from the start :-). Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
> I was wondering whether it was possible to implement "pooling" of stateless > pages? Possibly using a custom PageMap implementation? I think you can just implement the pooling mechanism yourself, and provide a custom version of IPageFactory (which is to be set in session settings). > Although newer JVM's are good at performing GC, pooling is a reasonable > additional technique to use for achieving that extra bit of scalability. Like other team members, I doubt this :-) Like any advantages you might have will be lost by the need to synchronize. And if your page is really heavy to construct, that is probably a sign that you should move your 'heavy code' (probably database access?) to the rendering phase (like using lazy initialized models and algorithms for components such as overriding isVisible rather than setting it). But nothing beats real numbers, and it may be worth it for your case. Let us know if it made a difference for you. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to reset the feedback panel
On Sun, May 18, 2008 at 6:15 PM, Michael Mehrle <[EMAIL PROTECTED]> wrote: > This works - thanks a lot. Cool. > BTW, was the JIRA request directed to me? Yes please. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
> I think it would probably make more sense to cache the /result/ of stateless > pages. Yeah, that might make quite the difference. The best place for that would be a filter, probably defined before the Wicket filter. Tons of different options as well though. And definitively something I would only investigate if I was either experience scaling problems or would have a scale that I would know upfront it might save a bunch of servers. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
On Sun, May 18, 2008 at 11:04 PM, James Carman <[EMAIL PROTECTED]> wrote: > stateless != static, though > > If you cache the results of a stateless page, you could show stale > information from the database, correct? True, so it depends on your use case. And obviously it wouldn't work for form processing either. But for - say - a catalogue site where hourly updates are good enough (in which case you would invalidate the cache every hour), it might be an option. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ReloadingWicketFilter for Classes in a referenced project?
> i'm trying to create a ReloadingWicketFilter. I've tried a lot especially > reading (WICKET-685) ReloadingWicketFilter not working with markup > inheritance ( > http://www.mail-archive.com/[EMAIL PROTECTED]/msg01938.html) but > nothing worked for me. I think a better way to go is to use JavaRebel. See http://www.zeroturnaround.com/javarebel/ Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Wicket and MySQL
> and i have made sure i have this jar > "mysql-connector-java-5.1.6-bin.jar" to my buid path... but the > problem goes on... Build path != runtime path. Make sure the jar is in your runtime path as well. FWIW, never ever write such code for a production application because you'll run into scalability problems pretty fast. At the very least, use a connection pool. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
On Tue, May 20, 2008 at 9:44 PM, Gerolf Seitz <[EMAIL PROTECTED]> wrote: > i have the fix for that in my local checkout and > will commit it sometime today. Cool. I just found out Wicket In Action's code (http://code.google.com/p/wicketinaction/) had compile errors. Ideally, Wicket 1.4 it should be completely backwards compatible. A copy from the errors Eclipse reports: The constructor RestartResponseAtInterceptPageException(Class) is undefined book-wicket-in-action/src/java/wicket/in/action/chapter12/authdiscounts UserPanel.java line 37 1211331768935 213000 The constructor RestartResponseAtInterceptPageException(Class) is undefined book-wicket-in-action/src/java/wicket/in/action/chapter13/locdiscounts UserPanel.java line 41 1211331768461 212926 The constructor RestartResponseAtInterceptPageException(Class) is undefined book-wicket-in-action/src/java/wicket/in/action/common WiaAuthorizationStrategy.java line 36 1211331766706 212722 The method setModelObject(capture#6-of ?) in the type Component is not applicable for the arguments (int) book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_1 HelloWorldTest.java line 91 1211331768160 212829 The method setObject(Object) of type CheeseModel must override a superclass method book-wicket-in-action/src/java/wicket/in/action/chapter04/section_4_3 Index.java line 42 1211331769904 213426 The method startPanel(TestPanelSource) in the type BaseWicketTester is not applicable for the arguments (Class) book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_1 HelloWorldTest.java line 66 1211331768160 212828 The return type is incompatible with Application.getHomePage() book-wicket-in-action/src/java/wicket/in/action WicketInActionApplication.java line 125 1211331770166 213591 The return type is incompatible with MarkupContainer.setModel(IModel) book-wicket-in-action/src/java/wicket/in/action/common AjaxEditableLabel.java line 129 1211331767509 212759 The return type is incompatible with Model.getObject() book-wicket-in-action/src/java/wicket/in/action/chapter03/section_3_2 Index.java line 61 1211331769986 213564 The return type is incompatible with Model.getObject() book-wicket-in-action/src/java/wicket/in/action/chapter03/section_3_3 Index.java line 61 1211331769970 213527 The return type is incompatible with Model.getObject() book-wicket-in-action/src/java/wicket/in/action/chapter03/section_3_3 ShoppingCartPanel.java line 32 1211331769946 213506 The return type is incompatible with Model.getObject() book-wicket-in-action/src/java/wicket/in/action/chapter04/section_4_2 Index.java line 120 1211331769917 213443 The return type is incompatible with Model.getObject() book-wicket-in-action/src/java/wicket/in/action/chapter04/section_4_3 Index.java line 29 1211331769904 213425 The return type is incompatible with Model.getObject() book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_3 Index.java line 113 1211331767771 212812 The return type is incompatible with Model.getObject() book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_3 Index.java line 132 1211331767771 212815 Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
On Wed, May 21, 2008 at 12:24 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> ok so we pretty much have some core people wanting to back out the
> generics support.
I hate to say it, and I kept myself on the background because I don't
want to be a pita, but I still feel the same as I did last year:
generic models are cool, generic components ugly. Unfortunately, a
large part of the ugliness is due to Java's lack of type inference,
which results in that you have to state the type twice as often as
really necessary.
What I hate most about how 1.4 currently looks is just the verbosity.
I like the advantages more static typing can give us (a major selling
point of Wicket after all), but at the same time I have to admit that
I rarely if ever run into casting or refactoring problems with 1.3.
Also, I found that using constructs like:
public class DomainObjectModel extends
LoadableDetachableModel
...
public SiteNodePanel(String id, DomainObjectModel rootNodeModel) {
work well enough for me, so I don't really miss generics in Wicket to
start with. (in the example I force that SiteNodePanel instances are
always created with a model that produces SiteNode objects).
> shall we start a vote? johan, gerolf and i have spent a ridiculous
> amount of time trying to generify the codebase and remove all the
> shitty warnings. if there is even a slight chance of this getting
> backed out i do not want to spend any more time on this until the
> issue is resolved.
I'd to thank you guys for the effort. It's really cool you put in that
hard work, even if the results aren't as good as you hoped.
> personally i do not mind backing out generics, they turned out to be
> quiet a disappointment for me as well, but my feelings about this are
> not strong.
>
> we can still use generics such as setresponsepage(class page>) to gain bits of typesafety here and there, but if we remove
> them from component we obviously have to remove them from imodel.
I would be all for just using generics where it really provides a huge
benefit and where opinions on it don't differ too much. A few hard
choices will have to be made and judging from the discussion so far,
I'm afraid at least a couple of people will end up being quite
unhappy.
> so lets start a vote with a parallel discussion thread just for this.
Good idea. Let's do discussion first (thread on dev?) and let's not
rush things. How about gathering consensus of the parts we currently
do like?
Cheers,
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] wicketstuff SVN reorganization...
> p.s. Sorry to be such a stickler, but I'm one of those folks who has > to have order. I can't work until I clean my desk up first! :) Haha. You must be popular with girls (at least the ones I know would love a guy like that)! ;-) +1 for doing a vote. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how can ..
On Fri, May 23, 2008 at 3:03 AM, Tomasz Prus <[EMAIL PROTECTED]> wrote: > What strategy should i use to achive such url: > http://isport.eu/en/premier-league/liverpool-fc/news-19-2008-0.html ? Please take a look at QueryStringUrlCodingStrategy and MixedParamUrlCodingStrategy. Wicket-examples has the 'stateless' example which is not really related to what you want, but uses those strategies. Play around with them and look at the code so that you understand what is going on. And consider creating your own BookmarkablePageRequestTargetUrlCodingStrategy extension if that works better for you. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket i18n options
Excellent! I didn't even know about that new feature (nested tags nested in wicket:message). Is that really only in 1.4? Eelco On Sun, May 25, 2008 at 6:09 AM, Erik van Oosten <[EMAIL PROTECTED]> wrote: > Hi, > > As there was no complete overview of Wicket's i18n options (even Wicket in > Action only lists a few), I decided to write an article on it. > > http://day-to-day-stuff.blogspot.com/2008/05/wicket-internationalization.html > > Feedback is welcome! > > Regards, > Erik. > > -- > Erik van Oosten > http://day-to-day-stuff.blogspot.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]
Re: Wicket i18n options
> Its in the release notes! Yeah, I should've read those better. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket i18n options
On Sun, May 25, 2008 at 1:58 PM, Eelco Hillenius <[EMAIL PROTECTED]> wrote: >> Its in the release notes! > > Yeah, I should've read those better. Though it surprises me that there would be anything other than generics in 1.4. The deal was very explicitly to only add generics in 1.4, and (other) new features would go to 1.5. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IVisitor bug?
And instead of bl.add(new SimpleAttributeModifier("class", "clazz"));
you could do tag.put("class", "clazz");. Or remove the attribute
altogether (tag.remove("class")) if it's only a dummy.
Eelco
On Tue, May 27, 2008 at 12:42 AM, Alex Parvulescu
<[EMAIL PROTECTED]> wrote:
> thanks Eelco,
> the problem is fixed!
>
> if anybody's interested:
> the visitor:
> public class ReadOnlyReplacingVisitor implements IVisitor {
>
> public Object component(Component component) {
>if (component instanceof DropDownChoice || component instanceof
> TextField) {
>String id = component.getId();
>// the label keep the old component's value
>InfoLabel lbl = new InfoLabel(id, component.getModel());
>// a little css sugar ;)
>lbl.add(new SimpleAttributeModifier("class", "clazz"));
>component.replaceWith(lbl);
>}
> }
> }
>
> and the new component:
> public class InfoLabel extends Label {
>
>public InfoLabel(String id) {
>super(id);
>}
>
>public InfoLabel(String id, IModel model) {
>super(id, model);
>}
>
>public InfoLabel(String id, String label) {
>super(id, label);
> }
>
> @Override
>protected void onComponentTag(ComponentTag tag) {
>super.onComponentTag(tag);
>tag.setName("span");
>}
> }
>
>
> On Tue, May 27, 2008 at 10:02 AM, Eelco Hillenius <[EMAIL PROTECTED]>
> wrote:
>
>> > I have a visitor that replaces components(TextField, DropDownChoice) on a
>> > page with read-only values (labels)
>> >
>> > this visitor doesn't work properly, it doesn't replace the entire
>> component,
>> > it only inserts the text between the component's tags
>> > so that becomes > > type="text">replaced
>> >
>> > and now some code:
>> >
>> > the visitor:
>> > public class ReadOnlyReplacingVisitor implements IVisitor {
>> >
>> > public Object component(Component component) {
>> >if (component instanceof DropDownChoice || component instanceof
>> > TextField) {
>> >String id = component.getId();
>> >component.replaceWith(new Label(id, "replaced"));
>> >}
>> > }
>> >
>> > }
>> >
>> > the page:
>> >
>> > for wicket 1.2.6 i have :
>> >@Override
>> >protected void onAttach() {
>> >visitChildren(new ReadOnlyReplacingVisitor());
>> >}
>> >
>> > wicket 1.3.3:
>> >@Override
>> >protected void onBeforeRender() {
>> >super.onBeforeRender();
>> >visitChildren(new ReadOnlyReplacingVisitor());
>> >}
>> >
>> > i tried to replace the simple Label component with a custom panel,but the
>> > outcome is the same
>> > this goes for DDCs as well.
>> >
>> > any ideas?
>>
>> Well, a label only replaces it's body, while what you want is change
>> the tag, right? One way to achieve that is to create a component that
>> does this (overwrite onComponentTag and use setName on the tag to
>> change the tag, and maybe change the attributes). I didn't actually
>> try this, but I think this should work.
>>
>> Eelco
>>
>> -
>> 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]
Re: more getting started documents
> is there any step by step CRUD for wicket? The phonebook example in wicket-stuff. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Back button problem with form
> After some debugging I solved it in a ugly way. I used PropertyModel() for > the form and when I > pressed submit the object did'nt update in a correct manner. I think it has > to do with that the object is in the session. Weird. Did you check that the target of the property model was the one you intended? It sounds like you might have been referring to a stale object. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
users, please give us your opinion: what is your take on generics with Wicket
Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [ ] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] 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. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is Wicket? from WIA
Wicket supports private state for individual components, whereas the traditional (REST) pattern assumes to take the state out (to string based request parameters) and up to the request level. The big difference is that without using a framework like Wicket, you can't really create self contained components. You have to ensure that state gets passed in any URL that is generated on a page, ensure the parameters are properly scoped, have to worry about how to serialize and de-serialize (from regular objects to strings and vice versa), etc. You can test this by creating a Struts app where you create a pageable list. You'd append parameters for e.g. the page number and query to every URL that passes back to the page, even if the link you are constructing has nothing to do with the pageable list. Just the fact that it is on the page means you have to pass the parameter. That by itself is doable - though destroys encapsulation -; the problems really start when you decide to move/ reuse the 'component' to/ in another page, and when e.g. you add more things to the pass that need to pass state like for instance tabs. Eelco On Sun, Jun 1, 2008 at 1:53 PM, Eyal Golan <[EMAIL PROTECTED]> wrote: > Hi, > I read chapter 1 in Wicket in Action and I have a question. > in section 1.2.1 it says: > "You can get rid of all of these problems by using Wicket. It is a > stateful framework, so you > don't have to follow the REST (though you can, but we will talk about > that later in this book) > approach. The main idea behind REST is scalability. Fine. But let me make a > bold statement here: > Very often, REST is premature optimization." > > Wicket is my first Web Framework and I was wondering if someone can explain > why Wicket solves the REST problem (which I understood the problem itself). > Is it because in Wicket we don;t need to pass parameters in the request? And > instead we create pages with the necessary information? (or something like > that) > > Thank > > -- > Eyal Golan > [EMAIL PROTECTED] > > Visit: http://jvdrums.sourceforge.net/ > LinkedIn: http://www.linkedin.com/in/egolan74 > - 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
On Sun, Jun 1, 2008 at 2:46 PM, Ayodeji Aladejebi <[EMAIL PROTECTED]> wrote: > scan this user forum, you will realize that there is no high demand for > generics in wicket from users. I am yet to see one user or thread here of > wicket users screeming out for generics addition. I think users has been > doing just fine without it at least speaking for myself. Well, there are at least a couple of long-time users that have been waiting around for more than a year for us to implement (or re-implement since it was in 2.0) this. But let's see what opinions this threads show us. > Anything more than IModel, I wont upgrade to 1.4 as well > > +1 for IModels only Thanks for giving your opinion. Eelco - 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
> IMHO storing a model in a Component is more a convenience than a > fundamental part of component-ness. This may be part of the reason that > genericizing Component is so contentious. I agree. Eelco - 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
On Mon, Jun 2, 2008 at 7:45 AM, Matej Knopp <[EMAIL PROTECTED]> wrote: > I'm not sure I like where this discussion is going. I don't see anyone > having any particular objections against current state. I think before > we even think of (partially) reverting generics we have to discuss > what's wrong (except the verbosity of course, but that's not something > we can really do about) with current state. I use wicket with generics > daily and I don't see any particular show stopper so far. I just want to get a hunch of what people are thinking at the moment. It's not meant to be a discussion thread, nor a decision thread. Eelco - 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
> Question is, how many of those users actually use generified wicket on > day-to-day basis. Common, a quick glance and comparing some of the code/ examples you see with the code you write now (with 1.2/ 1.3) is enough to get a good - and as far as I am concerned informed well enough - idea. Eelco - 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
On Tue, Jun 3, 2008 at 8:54 PM, Mike Comb <[EMAIL PROTECTED]> wrote: > Well, in our case it would almost never be: > > MyComponent mycom = new MyComponent(); > > We don't have many of our own models, we use CompoundPropertyModel pretty > much exclusively (wrapping DAOs or javabeans). So the verbosity doesn't > benefit us much. Also, the vast majority of our components don't have a > model. We generally have a page containing one or more forms with a > CompoundPropModel on each form. Having generics (particularly if they are > just something like ) on every other object in the page is messy and > confusing in my mind. Yep. > Telling people to use suppress annotations is not a good solution either, we > want those warnings for other things in our code (Collections, etc). Yep. Eelco - 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
On Tue, Jun 3, 2008 at 10:37 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > i think we should have qualified this rfi with a requirement that > responders use 1.4 on a non-trivial project...these things only become > apparent from real-world day-to-day usage. anything else is pretty > much speculation. Well, like I stated I just wanted to get a hunch of what people think, not so much an informed discussion. I think it is very clear now that whatever choice we'll ultimately stick to, it will make part of our user base unhappy, and might have to do some evangelizing to get the changes accepted by everyone (or most) :-) As for speculation... I don't agree. I haven't converted yet, but it is easy enough to just look at any old piece of code I'm working on now and imagine what it will look like after changing to 1.4. Eelco - 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
> it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. Eelco - 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
> Having multiple models is rare, however, having one model that can > (but doesn't have to) be used is more common imho. Not that rare if I look at my code, especially if you take panels and fragments into account. I have plenty of places where I use two or three models. > Wicket is kinda optimized for the later, so if you don't use the model there > is no > runtime cost associated. If we didn't have "default" model slot this > would be more difficult to achieve. The problem with generics now is that the model isn't as optional anymore. So you'd have to use void or whatever. Eelco - 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
On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > you still have ondetach()...but for convinience we can automatically > detach any imodel fields, i actually wanted to do this for a while... I tried to write this two days ago, but wasn't able to pull it off... I wrote an instantiation listener that introspected on the fields of components and replaced IModel members with a proxy. These proxies would register themselves with the request cycle for cleaning up whenever the getObject was called, and the request cycle then would go through the list of registered models and detach them at the end of the request. The problem I ran into however is that these members can be final, assigned at a later stage (typically are actually) and such. But if there is some way to automatically detach model members, we could get rid of the model member in component and instead just let components have models by default where it actually always makes sense, such as form components. Anyway, that's something for 1.5. If it is fixable, I think that would be the way out of the generics controversy :-) Eelco - 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
On Wed, Jun 4, 2008 at 9:52 AM, Matej Knopp <[EMAIL PROTECTED]> wrote: > I was talking about the model slot. If you don't have a model in > component it doesn't cost you anything. The cost in this case is the fact that having the model slot, even when not used, results in the assumption that a component is typed. Eelco - 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
On Wed, Jun 4, 2008 at 10:05 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > but IModel implementations can have Imodels inside too Whether done automatically or by components as we do now, ultimately the calls to detach will be the same, right? Eelco - 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
On Wed, Jun 4, 2008 at 10:10 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> sounds way too complicated to me dude...
>
> component.detach() {
> for (field:fields) {
>if (imodel.class.isassignablefrom(field.gettype)) {
>((imodel)field.get(this)).detach();
>}
> }
> onDetach();
> }
>
> with proper caching of the actual fields lookup this should be pretty
> performant
Maybe. I was trying to avoid having to introspect on every single detachment.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [FINALISED SCHEDULE] London Wicket Event at Google UK, tonight
> Is there a webcast? I'm interested in the Stateless vs. Stateful Me too. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does wicket favor composite session obj?
By default, Wicket will create separate session objects for each application. If you want to share info between multiple Wicket sessions, you'll have to access the underlying HttpSession object. Should be relatively easy to create an abstraction for that yourself. Eelco On Wed, Jun 4, 2008 at 11:57 AM, smallufo <[EMAIL PROTECTED]> wrote: > According to wicket API docs , I have a question. > Does wicket favor composite session object ? > That is , if my site has some independent apps , each has its custom setting > object. > It seems I have to associate these objects to one root session object : > > like this : > > App1Setting setting1 = ((RootSession)getSession()).getApp1Setting(); > App2Setting setting2 = ((RootSession)getSession()).getApp2Setting(); > > > Is it correct ? > - 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
On Wed, Jun 4, 2008 at 11:35 AM, Brill Pappin <[EMAIL PROTECTED]> wrote: > Thats a pretty major api change (although it looks simple) maybe that > should be in the next major release? It's something we can consider yeah. We'll have to think it through and get back to the drawing board to see what that means for how components and models work together though. Consistency is very important in an API like Wicket's, and consistency is imho a big + in how models and components currently work together. Eelco - 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
> I implemented this by hooking in to serialization, just checking each object > in ObjectOutputStream.replaceObject and ObjectInputStream.resolveObject. > Also had to use my own PageMapEntries to get a suitable hook. Might work as > an idea for your implementation perhaps? That's a cool idea for individual projects. For Wicket in general however, the problem would be that it wouldn't work for every session store (it wouldn't for instance for HttpSessionStore which doesn't serialize on each request). Also, 1.3's default session store serializes on each request, but does not reuse that serialized instance until the back button is used (or if you're doing session replication and come in through another node I guess). Are you sure your detachment works like you think it does? Eelco - 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
> Also, 1.3's default session store > serializes on each request, but does not reuse that serialized > instance until the back button is used (or if you're doing session > replication and come in through another node I guess). It keeps the 'current' page in memory, and reuses that when it can. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
