OT: Invitations available for http://careers.stackoverflow.com/

2011-07-25 Thread Brian Topping
Hi all,

Apologies for the somewhat off-topic email here.  
http://careers.stackoverflow.com/ is a pretty nifty job site that I signed up 
for recently, and I have 25 invitations to share.  

Besides it being a very nifty site with a lot of promise (will generate good 
looking resume PDFs automatically, for instance), it makes sense that the 
Wicket community should stack the deck with as many Wicket developers as we 
can.

If anyone would like an invite, please contact me off-list and I will be 
pleased to send one.

Cheers, Brian
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: best search engine framework to use with wicket

2011-07-16 Thread Brian Topping
Carl-Eric and Martin are right, Wicket just stays out of the way with respect 
to other frameworks.  It's literally just the presentation engine and does an 
awesome job at it.

If you want something that is automatic in this regard, you might want to take 
a look at Brix (http://brixcms.org).  Instead of pages being stored on the 
classpath, they are stored in a document-oriented database service, the 
interfaces to which (JCR) are used by over a dozen large-scale content 
management systems.  

In this way, your pages are easily modifiable by content authors without 
rebuilding the WAR, and it's also easier for Lucene to automatically index the 
content as it's changed.  Your content database must obviously be maintained 
with as much integrity as your transactional database and there are some 
additional configurations required for components, but otherwise it's just a 
regular Wicket application.

HTH, Brian

On Jul 16, 2011, at 6:58 AM, Carl-Eric Menzel wrote:

 On Sat, 16 Jul 2011 03:41:19 -0700 (PDT)
 hariharansrc hariharan...@gmail.com wrote:
 
 can anyone suggest the best search engine framework for wicket
 
 Wicket doesn't really care what other frameworks you use beside it.
 Wicket does nothing but the UI layer, and for everything else you can
 use whatever you want. Use Hibernate or IBatis or JPA or whatever for
 your DB access. Use Spring or Guice or whatever for your wiring. Use
 Hibernate Search or Lucene or whatever for your searching.
 
 Carl-Eric
 www.wicketbuch.de
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and OSGi

2011-06-25 Thread Brian Topping
It would be easier to contribute feedback to your project as well as easier to 
promote upstream if you forked the wicket-stuff project on github and added 
your project there.

On Jun 25, 2011, at 11:24 AM, Harald Wellmann wrote:

 Am 23.06.2011 19:11, schrieb Harald Wellmann:
 
 I'll take a look at the patches, play around with the code and find out
 if I'm one the wrong track or not... If I end up with anything
 interesting enough, I'll get back or attach another patch.
 
 
 Ok, here is my first shot at a solution. The IClassResolver using the client 
 bundle class loader works as expected. OSGi service injection into Wicket 
 components along the lines of wicket-spring is also working, as long as the 
 required services are unique.
 
 All the details are explained in a Wiki page [1], and the glue code can be 
 browsed online [2], or you can clone my sample repository from Google Code.
 
 Any feedback welcome!
 
 [1] http://code.google.com/p/osgi-enterprise/wiki/WicketAndOsgi
 [2] 
 http://code.google.com/p/osgi-enterprise/source/browse/?name=0.1.0#hg%2Faries-pde%2Fcom.googlecode.osgienterprise.wicket.osgi%2Fsrc%2Fcom%2Fgooglecode%2Fosgienterprise%2Fwicket
 
 Regards,
 Harald
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and OSGi

2011-06-24 Thread Brian Topping
It seems that Wicket should not be burdened with this tracking that is only 
used in OSGi configurations.  Another issue is that an admin will use OSGi 
interfaces to swap out bundles, not wicket interfaces.  OSGi is going to use 
the BundleActivator of the component bundle to stop it, and it won't know to 
tell the wicket core service anything about what it's doing to the component 
bundle.  Thus it needs to know whether and/or when it can unload.  

Once a bundle is in the STOPPING state, it's no longer an active service, so it 
cannot call other services or be called by them.  Yet, the tracking needs to be 
updated so the blocked call to stop can unblock, hence the weak reference 
collection.  

On Jun 23, 2011, at 8:05 PM, Igor Vaynberg wrote:

 i think the frameworks should track this. this way wicket can track
 what it is serializing and when it is letting it go. jetty can keep
 track of what it has in its http session.
 
 the serialization bundle should provide a way for bundles to tell it
 i am holding on to class A from bundle B and i no longer care about
 class C from bundle D
 
 -igor
 
 On Thu, Jun 23, 2011 at 6:48 PM, Brian Topping topp...@codehaus.org wrote:
 Good point.  This could be handled by the serializer maintaining a 
 WeakHashMap of the sessions that use a particular bundle and blocking in the 
 bundle activator's stop method until the list is empty.
 
 But if a user was busy for an extended period, like some kind of automated 
 scraper or monitor that ended up having the session open for days, the check 
 would have to be more granular than the session.  Which seems like it's 
 going to be different between 1.4 and 1.5 because of the migration from 
 pagemaps.
 
 On Jun 23, 2011, at 4:41 PM, Igor Vaynberg wrote:
 
 something else to consider - where this gets even hairier :)
 
 user accesses a page that has a component from bundle A, the page is 
 serialized.
 admin upgrades bundle A which has a new version of the component -
 that is not compatible serialization-wise
 user click back and the page needs to be serialized - error
 
 what is needed here i some way to veto a bundle/version removal until
 all web sessions that access components in those bundles have timed
 out. this is not really wicket-specific, more web specific as web apps
 can stick objects into http session...
 
 -igor
 
 
 On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping topp...@codehaus.org wrote:
 
 On Jun 23, 2011, at 10:11 AM, Harald Wellmann wrote:
 
 what is really needed here is someone taking the time to build a
 generic serialization mechanism for osgi. wicket's serialization is
 pluggable so it can be hooked into that.
 
 
 I'll take a look at the patches, play around with the code and find out 
 if I'm one the wrong track or not... If I end up with anything 
 interesting enough, I'll get back or attach another patch.
 
 I'm also taking a look at it.
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and OSGi

2011-06-24 Thread Brian Topping

On Jun 23, 2011, at 11:09 PM, Martin Grigorov wrote:

 This sounds like the problem solved with
 http://www.tomcatexpert.com/blog/2011/05/31/parallel-deployment-tomcat-7

Kind of assumes one is using Tomcat and not one of the other ways to deploy a 
web application with OSGi.  :-)
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and OSGi

2011-06-24 Thread Brian Topping
If by that you mean Wicket would be injected with something like the system 
classloader or wicket's classloader, it kind of breaks modularity.  How would 
one upgrade wicket itself?  There's no limitation to doing so, the new Wicket 
bundle can have dependencies in parallel with the old wicket bundle, but if the 
dependencies were holding on to the old wicket's classloader, seems like a 
problem.  

On Jun 24, 2011, at 12:39 AM, David Leangen wrote:

 
 IIUC, other frameworks allow for the injection of a classloader. Wouldn't 
 that be enough?
 
 We could then package an optional classloader just for that purpose.
 
 
 Cheers,
 =David
 
 
 
 On Jun 24, 2011, at 4:34 PM, Brian Topping wrote:
 
 It seems that Wicket should not be burdened with this tracking that is only 
 used in OSGi configurations.  Another issue is that an admin will use OSGi 
 interfaces to swap out bundles, not wicket interfaces.  OSGi is going to use 
 the BundleActivator of the component bundle to stop it, and it won't know to 
 tell the wicket core service anything about what it's doing to the component 
 bundle.  Thus it needs to know whether and/or when it can unload.  
 
 Once a bundle is in the STOPPING state, it's no longer an active service, so 
 it cannot call other services or be called by them.  Yet, the tracking needs 
 to be updated so the blocked call to stop can unblock, hence the weak 
 reference collection.  
 
 On Jun 23, 2011, at 8:05 PM, Igor Vaynberg wrote:
 
 i think the frameworks should track this. this way wicket can track
 what it is serializing and when it is letting it go. jetty can keep
 track of what it has in its http session.
 
 the serialization bundle should provide a way for bundles to tell it
 i am holding on to class A from bundle B and i no longer care about
 class C from bundle D
 
 -igor
 
 On Thu, Jun 23, 2011 at 6:48 PM, Brian Topping topp...@codehaus.org wrote:
 Good point.  This could be handled by the serializer maintaining a 
 WeakHashMap of the sessions that use a particular bundle and blocking in 
 the bundle activator's stop method until the list is empty.
 
 But if a user was busy for an extended period, like some kind of automated 
 scraper or monitor that ended up having the session open for days, the 
 check would have to be more granular than the session.  Which seems like 
 it's going to be different between 1.4 and 1.5 because of the migration 
 from pagemaps.
 
 On Jun 23, 2011, at 4:41 PM, Igor Vaynberg wrote:
 
 something else to consider - where this gets even hairier :)
 
 user accesses a page that has a component from bundle A, the page is 
 serialized.
 admin upgrades bundle A which has a new version of the component -
 that is not compatible serialization-wise
 user click back and the page needs to be serialized - error
 
 what is needed here i some way to veto a bundle/version removal until
 all web sessions that access components in those bundles have timed
 out. this is not really wicket-specific, more web specific as web apps
 can stick objects into http session...
 
 -igor
 
 
 On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping topp...@codehaus.org 
 wrote:
 
 On Jun 23, 2011, at 10:11 AM, Harald Wellmann wrote:
 
 what is really needed here is someone taking the time to build a
 generic serialization mechanism for osgi. wicket's serialization is
 pluggable so it can be hooked into that.
 
 
 I'll take a look at the patches, play around with the code and find out 
 if I'm one the wrong track or not... If I end up with anything 
 interesting enough, I'll get back or attach another patch.
 
 I'm also taking a look at it.
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail

Re: Wicket and OSGi

2011-06-24 Thread Brian Topping
wicket-bundle appears to be simply using assembly plugin to mash all the jars 
together.  

I haven't tested it yet, but I believe 
https://github.com/topping/wicket/commit/b120bdd4e6b7b085f2644aab1f77b3d40558c967
 is a better solution.

Haven't found OsgiClassResolver yet, but it's late here and I'm going to bed.

On Jun 24, 2011, at 12:50 AM, Martin Grigorov wrote:

 OsgiClassResolver will be in wicket-bundle.jar (the one in wicketstuff).
 The user application will use it by:
 
 MyApp#init() {
  super.init();
  getApplicationSettings.setClassResolver(new OsgiClassResolver());
 }
 
 
 On Fri, Jun 24, 2011 at 10:46 AM, Brian Topping topp...@codehaus.org wrote:
 If by that you mean Wicket would be injected with something like the system 
 classloader or wicket's classloader, it kind of breaks modularity.  How 
 would one upgrade wicket itself?  There's no limitation to doing so, the new 
 Wicket bundle can have dependencies in parallel with the old wicket bundle, 
 but if the dependencies were holding on to the old wicket's classloader, 
 seems like a problem.
 
 On Jun 24, 2011, at 12:39 AM, David Leangen wrote:
 
 
 IIUC, other frameworks allow for the injection of a classloader. Wouldn't 
 that be enough?
 
 We could then package an optional classloader just for that purpose.
 
 
 Cheers,
 =David
 
 
 
 On Jun 24, 2011, at 4:34 PM, Brian Topping wrote:
 
 It seems that Wicket should not be burdened with this tracking that is 
 only used in OSGi configurations.  Another issue is that an admin will use 
 OSGi interfaces to swap out bundles, not wicket interfaces.  OSGi is going 
 to use the BundleActivator of the component bundle to stop it, and it 
 won't know to tell the wicket core service anything about what it's doing 
 to the component bundle.  Thus it needs to know whether and/or when it can 
 unload.
 
 Once a bundle is in the STOPPING state, it's no longer an active service, 
 so it cannot call other services or be called by them.  Yet, the tracking 
 needs to be updated so the blocked call to stop can unblock, hence the 
 weak reference collection.
 
 On Jun 23, 2011, at 8:05 PM, Igor Vaynberg wrote:
 
 i think the frameworks should track this. this way wicket can track
 what it is serializing and when it is letting it go. jetty can keep
 track of what it has in its http session.
 
 the serialization bundle should provide a way for bundles to tell it
 i am holding on to class A from bundle B and i no longer care about
 class C from bundle D
 
 -igor
 
 On Thu, Jun 23, 2011 at 6:48 PM, Brian Topping topp...@codehaus.org 
 wrote:
 Good point.  This could be handled by the serializer maintaining a 
 WeakHashMap of the sessions that use a particular bundle and blocking in 
 the bundle activator's stop method until the list is empty.
 
 But if a user was busy for an extended period, like some kind of 
 automated scraper or monitor that ended up having the session open for 
 days, the check would have to be more granular than the session.  Which 
 seems like it's going to be different between 1.4 and 1.5 because of the 
 migration from pagemaps.
 
 On Jun 23, 2011, at 4:41 PM, Igor Vaynberg wrote:
 
 something else to consider - where this gets even hairier :)
 
 user accesses a page that has a component from bundle A, the page is 
 serialized.
 admin upgrades bundle A which has a new version of the component -
 that is not compatible serialization-wise
 user click back and the page needs to be serialized - error
 
 what is needed here i some way to veto a bundle/version removal until
 all web sessions that access components in those bundles have timed
 out. this is not really wicket-specific, more web specific as web apps
 can stick objects into http session...
 
 -igor
 
 
 On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping topp...@codehaus.org 
 wrote:
 
 On Jun 23, 2011, at 10:11 AM, Harald Wellmann wrote:
 
 what is really needed here is someone taking the time to build a
 generic serialization mechanism for osgi. wicket's serialization is
 pluggable so it can be hooked into that.
 
 
 I'll take a look at the patches, play around with the code and find 
 out if I'm one the wrong track or not... If I end up with anything 
 interesting enough, I'll get back or attach another patch.
 
 I'm also taking a look at it.
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 -
 To unsubscribe, e-mail

Re: Wicket and OSGi

2011-06-23 Thread Brian Topping

On Jun 23, 2011, at 10:11 AM, Harald Wellmann wrote:

 what is really needed here is someone taking the time to build a
 generic serialization mechanism for osgi. wicket's serialization is
 pluggable so it can be hooked into that.
 
 
 I'll take a look at the patches, play around with the code and find out if 
 I'm one the wrong track or not... If I end up with anything interesting 
 enough, I'll get back or attach another patch.

I'm also taking a look at it.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and OSGi

2011-06-23 Thread Brian Topping
Good point.  This could be handled by the serializer maintaining a WeakHashMap 
of the sessions that use a particular bundle and blocking in the bundle 
activator's stop method until the list is empty.  

But if a user was busy for an extended period, like some kind of automated 
scraper or monitor that ended up having the session open for days, the check 
would have to be more granular than the session.  Which seems like it's going 
to be different between 1.4 and 1.5 because of the migration from pagemaps.  
 
On Jun 23, 2011, at 4:41 PM, Igor Vaynberg wrote:

 something else to consider - where this gets even hairier :)
 
 user accesses a page that has a component from bundle A, the page is 
 serialized.
 admin upgrades bundle A which has a new version of the component -
 that is not compatible serialization-wise
 user click back and the page needs to be serialized - error
 
 what is needed here i some way to veto a bundle/version removal until
 all web sessions that access components in those bundles have timed
 out. this is not really wicket-specific, more web specific as web apps
 can stick objects into http session...
 
 -igor
 
 
 On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping topp...@codehaus.org wrote:
 
 On Jun 23, 2011, at 10:11 AM, Harald Wellmann wrote:
 
 what is really needed here is someone taking the time to build a
 generic serialization mechanism for osgi. wicket's serialization is
 pluggable so it can be hooked into that.
 
 
 I'll take a look at the patches, play around with the code and find out if 
 I'm one the wrong track or not... If I end up with anything interesting 
 enough, I'll get back or attach another patch.
 
 I'm also taking a look at it.
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Blog on my experiences learning Wicket

2011-06-08 Thread Brian Topping

On Jun 8, 2011, at 12:54 PM, Brian Lavender wrote:

 And yes, my blog uses Wordpress, not Wicket quite yet.


If you are going to make your blog out of Wicket, you might want to consider 
using Brix (http://www.brixcms.org).  It welds a NoSQL document database to 
Wicket, along with some basic page management functionality, providing the most 
important parts of a content management system to Wicket, which of course 
provides the best of component-oriented web development in Java.  

In the end, you get a content management system with dynamic components that 
are written the Wicket way.  Imagine your HTML being stored in a database that 
is accessible to non-technical folks, without losing the power of Wicket 
components.  That's Brix!

If you check it out, the Brix demo app is a great place to start.

Congrats on your work and welcome to Wicket!

Cheers, Brian
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket newbie seeks redirect idiom

2011-05-30 Thread Brian Topping
Here's a few thoughts:

1) Instead of all the redirecting around, put the unauthenticated content on 
the root page.  If the user is authenticated, redirect them to a url such as 
/users and make everything below that mount protected.  People don't pay much 
attention to URLs any more anyway.  Don't get too attached to your URLs looking 
pretty, but if you must, deal with them at the end by creating mount points.

2) Protecting everything below certain mount points can be done with servlet 
filters on path components, but remember that this is not the native 
representation of a Page in Wicket.  If you forget to make a mount for a page 
that should be protected, it can be accessed by someone who knows where to find 
it (generally a user that sees the page, then logs out and does something bad 
as if they are logged in).

3) Consider creating pages that can act differently, depending on the access 
rights of the current user.  By using the @AuthorizeInstantiation annotation 
(and the appropriate support behind it), you can disable and enable components 
declaratively.  So your home page can serve both authorized and unauthorized 
users.  By having components display something grayed out (for instance) 
instead of real data, you can tease users into becoming paid users.

4) Connect @AuthorizeInstantiation to a standardized security manager such as 
Wicket Auth Roles, Shiro, or Spring Security.  It's easy enough to implement 
IAuthorizationStrategy and do it yourself, but Wicket Auth Roles is very 
comprehensive and will open your thought process up to more of what is 
possible.  Shiro and Spring Security are more powerful still (for instance with 
cookie-managed security, integration with data sources such as LDAP, and other 
benefits).  

Start with a few of these in order, but don't get too lost in trying to do all 
of this out of the gate. 

On May 30, 2011, at 7:32 PM, Mark Petrovic wrote:

 Hello.  I just finished reading Wicket In Action, and now I'm working
 on my first Wicket app.  I have a simple question about page
 redirects.
 
 My application's homepage is WelcomePage.java, which I have mounted on
 /welcome.  However, if the user has already authenticated and they
 have a session, I would like to immediately send them to HomePage.java
 if they happen to browse to /welcome.  HomePage.java is a protected
 page that contains stuff only a logged user can see.  Whereas
 WelcomePage.java is the unauthenticated user's restricted view of the
 site.
 
 As a first step, I have chosen to implement this redirect in the
 WelcomePage ctor as follows:
 
public WelcomePage(PageParameters parameters) {
  add(new Label(message, blah));
 
if (AppSession.get().isAuthenticated()) {
setResponsePage(HomePage.class);
}
}
 
 While checking the session for an authenticated user and setting the
 response page to HomePage.class seems to work, I don't know if it
 represents the Wicket Way.  I was thinking there may be a more
 elegant way to affect the redirect, perhaps with one of the Page
 lifecycle methods.
 
 Would someone who has been here be kind enough to comment?
 
 Thank you.
 
 
 -- 
 Mark
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket's Wizard Component

2011-05-21 Thread Brian Topping
Wizard probably ought to be moved to the category of example code instead of 
something that can (or will) be improved.  It hasn't changed much since it was 
written, and if it were changed, would probably break hundreds of users for no 
real benefit (i.e. users would have to go implement new interfaces for 
components that already work and have long since been forgotten about).

IMHO, if you like the code, you might be better off just grabbing a copy of it 
into your own source tree.  Then you can build what you want with impunity.

Brian


On May 21, 2011, at 11:08 AM, Corbin, James wrote:

 I am attempting to enhance the Wizard's layout by sub-classing Wizard.java.  
 The idea is to change the default markup to suit some specific layout 
 requirements.
 
 
 The problem I am trying to solve is to re-parent the form to the component 
 bound to the wicket:id myOuterWrapperComp, but not sure if or how this can 
 be done using the Wizard framework.
 
 
 
 I am using Wicket Version 1.4.13.
 
 
 
 Can this be done using sub-classing Wizard.java? I would like to avoid 
 writing my own class that mimics 99% of what  Wizard.java provides, just for 
 this layout issue.
 
 Here is a sample of the markup in my DerivedFromWizard (not real name) class,
 
 
 div wicket:id=myOuterWrapperComp class=wicketExtensionsWizard
 
 
 
 form wicket:id=form class=wicketExtensionsWizardForm
 
 
 
 ... rest of wizard markup, same as what is in Wizard.html
 
 
 
 /form
 
 
 
 /div
 
 
 
 
 
 Thanks,
 J.D.
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket's Wizard Component

2011-05-21 Thread Brian Topping
Everything including Wizard has the ASL 2.0 copyleft at the top, which grants 
free and unrestricted use for commercial and non-commercial purposes.

On May 21, 2011, at 11:40 AM, Corbin, James wrote:

 To the core wicket developers, is there any copyright concerns with pulling 
 the Wizard source into my codebase and modifying it?
 
 J.D.
 
 -Original Message-
 From: Corbin, James [mailto:jcor...@iqnavigator.com] 
 Sent: Saturday, May 21, 2011 9:37 AM
 To: users@wicket.apache.org
 Subject: RE: Wicket's Wizard Component
 
 Actually, it makes sense to pull the source and modify it to support my 
 specific needs.
 
 J.D.
 
 -Original Message-
 From: Brian Topping [mailto:topp...@codehaus.org] 
 Sent: Saturday, May 21, 2011 9:29 AM
 To: users@wicket.apache.org
 Subject: Re: Wicket's Wizard Component
 
 Wizard probably ought to be moved to the category of example code instead 
 of something that can (or will) be improved.  It hasn't changed much since it 
 was written, and if it were changed, would probably break hundreds of users 
 for no real benefit (i.e. users would have to go implement new interfaces for 
 components that already work and have long since been forgotten about).
 
 IMHO, if you like the code, you might be better off just grabbing a copy of 
 it into your own source tree.  Then you can build what you want with impunity.
 
 Brian
 
 
 On May 21, 2011, at 11:08 AM, Corbin, James wrote:
 
 I am attempting to enhance the Wizard's layout by sub-classing Wizard.java.  
 The idea is to change the default markup to suit some specific layout 
 requirements.
 
 
 The problem I am trying to solve is to re-parent the form to the component 
 bound to the wicket:id myOuterWrapperComp, but not sure if or how this can 
 be done using the Wizard framework.
 
 
 
 I am using Wicket Version 1.4.13.
 
 
 
 Can this be done using sub-classing Wizard.java? I would like to avoid 
 writing my own class that mimics 99% of what  Wizard.java provides, just for 
 this layout issue.
 
 Here is a sample of the markup in my DerivedFromWizard (not real name) class,
 
 
 div wicket:id=myOuterWrapperComp class=wicketExtensionsWizard
 
 
 
 form wicket:id=form class=wicketExtensionsWizardForm
 
 
 
 ... rest of wizard markup, same as what is in Wizard.html
 
 
 
 /form
 
 
 
 /div
 
 
 
 
 
 Thanks,
 J.D.
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Authorization through Spring Security

2010-12-24 Thread Brian Topping
The key for using Wicket authorization annotations is to implement 
IAuthorizationStrategy and IUnauthorizedComponentInstantiationListener.  When 
you get called in those methods, you can call out to Spring Security to check 
how to proceed.  Just implement the methods with stubs, set breakpoints there, 
and look at what you are passed.  All will be clear, it's really easy to use.  

Doing it with intercept URLs might work for a few pages that you have mounted 
in Wicket, but in the end, every new page is going to have to be set up 
perfectly.  It's not worth it go go that route.

Brian

On Dec 24, 2010, at 2:38 AM, Dmytro Seredenko wrote:

 Guys,
 
 did anyone use Spring Security intercept-url for managing authorization
 for Wicket-driven webapp?
 
 It's still unclear to me: can I use SS 3 as an authorization tool with
 configuration like:
 
 security:http create-session=never auto-config=true
   security:intercept-url pattern=/admin access=ROLE_ADMIN/
   security:intercept-url pattern=/**/
 /security:http
 
 or there is no way to omit wicket-auth-roles?
 
 P.S. Although Wicket 'auth' annotations work, I couldn't make it work with
 Spring Security only.
 
 Thanks,
 Dmytro.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Oracle Wicket Starter Application Project

2010-12-21 Thread Brian Topping

On Dec 21, 2010, at 5:14 PM, Andrew Hall wrote:

 It'd be fair to say that some of my Java may not be of the highest standard, 
 so if anyone has the inclination to look at this, any constructive feedback 
 would be appreciated.

I've thought about how to use the database this way as well.  Eelco has a great 
question about database connection pooling, and I thought I would browse the 
source to see what was going on in there.  DBA or not, if the application could 
be made scalable this way, I'd be down (at least on PostgreSQL).

Unfortunately, the project is using Gradle, which does not import into my IDE 
(IntelliJ IDEA). 

It probably doesn't make sense to start that particular religious war in this 
thread, but practically, if I can't pull in the project and all it's 
dependencies very easily, I'm going to be less inclined to put any effort into 
it Right Now.  If some percentage of users think like me, then that is a 
percentage of users that will come very late to your ideas.  

$0.02...
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: [OT] Plugin WicketForge 0.8.1 available for IDEA 9+

2010-12-14 Thread Brian Topping
I was finally able to download the new version of WicketForge today (along with 
some other plugins) since IntelliJ recently updated their caches.

Minas, the results are beautiful.  ~minas++ !!!

:B

On Dec 1, 2010, at 5:59 PM, Minas Manthos wrote:

 
 Thanks guys! I'm glad you like it... It's nice to get some positive
 feedback... :-)
 
 PS: ok, next time i will post it as [ANN] ;-)
 
 -- 
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/OT-Plugin-WicketForge-0-8-1-available-for-IDEA-9-tp3066018p3068223.html
 Sent from the Users forum mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: [OT] Plugin WicketForge 0.8.1 available for IDEA 9+

2010-12-14 Thread Brian Topping
Well, he couldn't have done it without you.  Cheers to both of you guys :-)

On Dec 14, 2010, at 11:22 PM, Nick Heudecker wrote:

 He's really been doing a great job with it.
 
 On Tue, Dec 14, 2010 at 6:49 PM, Brian Topping topp...@codehaus.org wrote:
 
 I was finally able to download the new version of WicketForge today (along
 with some other plugins) since IntelliJ recently updated their caches.
 
 Minas, the results are beautiful.  ~minas++ !!!
 
 :B
 
 On Dec 1, 2010, at 5:59 PM, Minas Manthos wrote:
 
 
 Thanks guys! I'm glad you like it... It's nice to get some positive
 feedback... :-)
 
 PS: ok, next time i will post it as [ANN] ;-)
 
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/OT-Plugin-WicketForge-0-8-1-available-for-IDEA-9-tp3066018p3068223.html
 Sent from the Users forum mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: [OT] Plugin WicketForge 0.8.1 available for IDEA 9+

2010-12-01 Thread Brian Topping

On Dec 1, 2010, at 4:43 AM, Paul Szulc wrote:

 this is definitely not off topic :)

Have to agree 110%.  The IntelliJ experience is made whole with this plugin.

Congrats guys, and thanks for all the work!

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket 1.4.14 and WiQuery Tabs

2010-11-30 Thread Brian Topping

On Nov 30, 2010, at 12:30 PM, Brad Grier wrote:

 not sure how else to pin this down. 

If it were me, I would diff the generated HTML, then narrow down which 
component(s) is/are causing the headache, THEN diff changes in those 
components.  As well because it's a great way to learn more about the code in 
the process instead of just being numbed by the volume of changes...
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket 1.4.14 and WiQuery Tabs

2010-11-30 Thread Brian Topping
Maybe find the contributions in the source tree, look for references in the 
code to that filename.  Set a breakpoint on the code that normally contributes 
it, run the old code that works.  

When you hit the breakpoint, set more breakpoints a reasonably relevant 
distance back up the call chain (the caller, the caller's caller, etc).

Now run it with the broken code and the breakpoints in the same places and see 
what decisions are being made differently, why the call chain never makes it as 
deep as the working configuration.

You can do all this statically (i.e. with find usages searches), but the use 
of interfaces with multiple implementations can obscure the food chain unless 
you really know what to look for.

On Nov 30, 2010, at 5:49 PM, Brad Grier wrote:

 When I look at a diff from the ajax debug window between the failed 1.4.14 
 request and the 1.4.12, it's obvious the wiquery javascript resources aren't 
 being contributed in the error scenarios. Any thoughts on where to look in 
 Wicket to see why these contributions are failing?
 
 -Original Message- From: Brian Topping
 Sent: Tuesday, November 30, 2010 11:54 AM
 To: users@wicket.apache.org
 Subject: Re: Wicket 1.4.14 and WiQuery Tabs
 
 
 On Nov 30, 2010, at 12:30 PM, Brad Grier wrote:
 
 not sure how else to pin this down.
 
 If it were me, I would diff the generated HTML, then narrow down which 
 component(s) is/are causing the headache, THEN diff changes in those 
 components.  As well because it's a great way to learn more about the code in 
 the process instead of just being numbed by the volume of changes...
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket 1.4.14 and WiQuery Tabs

2010-11-29 Thread Brian Topping

On Nov 29, 2010, at 12:04 PM, Brad Grier wrote:

 After 1.4.14 wiquery tab components no longer render in my application. These 
 tabs are sitting on panels displayed via ajax so perhaps it’s something to do 
 with the css/javascript contribution. Interestingly the wiquery accordions 
 still work fine.

Since I was due to upgrade this as well and am using both wiquery accordions 
and tabs, I thought I would give it a try.  My tabs are on panels that are 
triggered by selections in the accordions (hey, are we working on the same 
source tree? ;-)).  But I'm unable to replicate this, everything is rendering 
fine.  

If I can assist by checking any specific rendering or you want a snippet of the 
HTML that's being generated on my end to help you debug, feel free to contact 
me off-list.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket 1.4.14 and WiQuery Tabs

2010-11-29 Thread Brian Topping

On Nov 29, 2010, at 2:39 PM, Brad Grier wrote:

 My tabs are on panels that get swapped in and out via ajax. Are you using 
 this approach? 

They are ajax, but I haven't bothered looking at how it works.  Here's what I 
use in populateItem():

 mainContentPanel = 
 cp.loadComponentInstance(mainContentPanel);
 mainContentPanel.setOutputMarkupId(true);
 AdminPage.this.replace(mainContentPanel);
 target.addComponent(mainContentPanel);

Hopefully that's relatively future-proof...



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket 1.4.14 and WiQuery Tabs

2010-11-29 Thread Brian Topping

On Nov 29, 2010, at 3:02 PM, Brian Topping wrote:

 
 On Nov 29, 2010, at 2:39 PM, Brad Grier wrote:
 
 My tabs are on panels that get swapped in and out via ajax. Are you using 
 this approach? 
 
 They are ajax, but I haven't bothered looking at how it works.  Here's what I 
 use in populateItem():
 
mainContentPanel = 
 cp.loadComponentInstance(mainContentPanel);
mainContentPanel.setOutputMarkupId(true);
AdminPage.this.replace(mainContentPanel);
target.addComponent(mainContentPanel);

Erm, that should have been what I use in my onClick()...


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket 1.4.14 and WiQuery Tabs

2010-11-29 Thread Brian Topping
Ah, great point.  I am already using 1.1.1!

On Nov 29, 2010, at 4:34 PM, julien roche AKA indiana_jules wrote:

 Hi all,
 
 Can you try tabs with the last release of wiquery ? (the 1.1.1). A lot of
 changes and refactoring were don into the core. Maybe that will solved your
 problems.
 
 Can you give me your feedbacks please .
 
 Thank you
 
 Regards
 
 Julien Roche
 
 On Mon, Nov 29, 2010 at 9:33 PM, Brad Grier brad.gr...@salusnovus.comwrote:
 
 Okay, well...it's more than a contribution problem. It looks like the tab's
 associated div, ul and li tags do not get modified by wiquery in 1.4.14.
 WiQuery assigns classes to these tags (ui-tabs, ui-tabs-nav,
 ui-state-default, etc). Those are all missing when I run in Wicket 1.4.14.
 
 Since it works fine for you, I'm not sure where to look.
 
 
 
 -Original Message- From: Brian Topping
 Sent: Monday, November 29, 2010 2:04 PM
 
 To: users@wicket.apache.org
 Subject: Re: Wicket 1.4.14 and WiQuery Tabs
 
 
 On Nov 29, 2010, at 3:02 PM, Brian Topping wrote:
 
 
 On Nov 29, 2010, at 2:39 PM, Brad Grier wrote:
 
 My tabs are on panels that get swapped in and out via ajax. Are you using
 this approach?
 
 
 They are ajax, but I haven't bothered looking at how it works.  Here's
 what I use in populateItem():
 
   mainContentPanel =
 cp.loadComponentInstance(mainContentPanel);
  mainContentPanel.setOutputMarkupId(true);
  AdminPage.this.replace(mainContentPanel);
  target.addComponent(mainContentPanel);
 
 
 Erm, that should have been what I use in my onClick()...
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Announcing the Topicus Dashboard

2010-11-24 Thread Brian Topping
Everyone note:  If you aren't on FB and need to register manually, the voting 
pages DO NOT place a vote for you once you register.  You must GO BACK TO THE 
PAGE and then place your vote after you activate your account.

(No promotional fees were paid for this public service announcement.)

On Nov 24, 2010, at 7:28 PM, Martijn Dashorst wrote:

 The Topicus Dashboard is an information radiator showing build status,
 production server status, twitter timeline, train departure times,
 important events and much more.
 
 The Atlassian folks are running a competition for the Ultimate
 Wallboard and we (Topicus)  just submitted our entry for the
 competition: the Topicus Dashboard.
 
 If you like our dashboard, you are welcome to vote for it and help us
 win the 55 flatscreen display in the Atlassian (known for JIRA and
 Confluence) Ultimate Wallboard Competition:
 
http://ultimatewallboard.com/entries/91860
 
 The entry sports a movie (the guy in the picture is Emond, a co-worker
 at Topicus)
 
 As we like to share our innovations we hosted our dashboard on github,
 and you are free to run the software and modify it for your own use
 (or your customers). The software is currently licensed using the GPL
 3.
 
 The project can be found here: https://github.com/dashorst/dashboard
 
 Most of the credits for this project go to Emond Papegaaij (and if you
 find a bug, call him, not me :)
 
 On behalf of the dashboard developers,
 
 Martijn Dashorst
 
 PS. Really: please vote and let us win the big screen TV!
 
 -- 
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: how to have one app at multiple root contexts

2010-11-22 Thread Brian Topping

On Nov 22, 2010, at 12:58 PM, Jim Pinkham wrote:

 For the security, I found a great help
 herehttp://out-println.blogspot.com/2009/02/wicket-swarm-spring-security-how-to.html.
 Unfortunately, it doesn't work with Wicket 1.5.  Anyone working on that?  I

Wicket-swarm was one of the first security frameworks for Wicket and is one of 
the more difficult ways to secure a Wicket application.  Wicket apps are 
actually exceptionally easy to secure and one is almost *always* better off 
growing their own security environment some apps need RBAC, others just 
need single-role authorization.

My suggestion is to implement IAuthorizationStrategy and 
IUnauthorizedComponentInstantiationListener with a stubbed class that always 
authorizes (i.e. always returns true) for each method.  Hook that class in, set 
a breakpoint on each method, then see what parameters are being passed.  Like a 
flash of white light, it will all become seriously obvious to you.

I'm currently using Spring Security and the Oauth module in my Wicket app, and 
I'm happy to tell you it works great.  As Spring has moved further and further 
toward namespace configuration, getting the beans wired properly has become 
somewhat difficult (they assume that you are securing a WebMVC application), 
but it's not impossible by any means.

Hope that helps...
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket ajax-enabled enclosures

2010-11-09 Thread Brian Topping
It's the same pattern as the last suggestion you had: 

1) Generate a patch with a Quickstart that demonstrates the proposed 
functionality
2) Attach it to a Jira issue

First impressions matter a lot, so if you post the Jira without the code, it's 
going to get ignored, possibly even after you post the code, which would waste 
your time.

Why not get yourself organized and present yourself professionally?  You sound 
eager and capable, show people your best!

Brian

On Nov 9, 2010, at 10:39 AM, Martin Makundi wrote:

 Hi!
 
 Has this been attempted before? Would it be a good idea to go at it?
 Sure would help removing some boilerplate webmarkupcontainer code.
 Existing jira issue for this?
 
 **
 Martin
 
 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com:
 Hi!
 
 Does wicket:enclosure have capability to setOutputMarkupPlaceholderTag ?
 
 What I mean is that when I have:
 wicket:enclosure child=optional-field
 tr
   tdoptional content/td
tdinput type=text wicket:id=optional-field//td
 /tr
 /wicket
 
 If I set it invisible via ajax I cannot set it visible again.
 
 Instead, is there a way to do something like:
 
 
 tr wicket:enclosure=child:optional-field
   tdoptional content/td
tdinput type=text wicket:id=optional-field//td
 /tr
 
 So that it would automatically handle visible/hidden
 setOutputMarkupPlaceholderTag flavour so that I can repaint a hidden
 element via ajax?
 
 @See http://jawher.wordpress.com/2009/09/17/wicket-enclosures-and-ajax-no-no/
 
 
 **
 Martin
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Are there any cases when I can rearrange component tree?

2010-11-09 Thread Brian Topping
This isn't a big limitation, all you have to do is store the state in an object 
separate from the component hierarchy. Then have the components access that 
shared state.  Keep MVC principles in mind:  The model is your state, the 
component is the controller.  

On Nov 9, 2010, at 10:41 PM, Dmitry Grigoriev wrote:

 Hello all,
 
 I'm new to Wicket. Just wonder about subj (theoretical interest). On one
 hand, stateful component model has no architectural limitations on its
 own preventing me from reattaching component to different parent, just
 like I can do with desktop applications or with any self-contained tree
 structure. On another hand, Wicket's component tree structure is bound
 to hard-coded markup, making such change-of-parent impossible.Is there
 any opportunity to do this? (No matter how sophisticated.)
 
 The reason for my interest is that I'm collecting ideas for stateless
 components support in my web framework. Stateless component hierarchy
 would likely be immutable (hard-coded into application logic rather than
 state) which looks like a significant limitation at first sight,
 compared to do-anything-you-want desktop programming. But I don't yet
 have much experience with web component frameworks and don't know is
 this limitation really annoying or not. For now it seems to me that
 Wicket has this limitation too but does not suffer a lot from it. Am I
 right?
 
 Thanks.
 
 -- 
 Cheers,
 dimgel
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Free wicket from component hierarchy hell

2010-11-05 Thread Brian Topping

On Nov 5, 2010, at 3:01 PM, Martin Makundi wrote:

 Duh.. I think there can be _no_ excuse to not reduce manual work where
 it is really not needed. It's not like we are talking about airline
 autopilots here.

So we don't need Wicket to work predictably and reliably all the time?  

MTBF is a composite factor of all weaknesses, what happens when the next weak 
hacks are added?  MTBF goes down exponentially.  Do Not Want.

As a dev, I really don't have a problem with assigning id attributes.  And 
while I see cases where folks in this thread have identified areas where your 
proposal *could* work *much of the time*, I am 100% concerned about total cost 
of ownership, which is directly linked to maintainability.  

Putting on my stakeholder hat, I don't care if my developers have to type 
wictrlspace a thousand times if it means the code cannot be blindly 
refactored in the future by people who are completely unfamiliar with how the 
original code was written.  Do Not Want. 

You might want to do some research on a version that was once considered 
Wicket 2.0.  It was a valiant effort by everyone involved, but eventually was 
one of those paths that had too much risk and did not end well.  It wasn't just 
a problem for the framework developers (who also need to put bread on their 
families tables at the end of the day), but also for users who started coding 
to it and had to significantly refactor their applications when it ultimately 
didn't work.  

Wicket is open source though.  Start a branch and prove your theory works!  :-)

Brian
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Free wicket from component hierarchy hell

2010-11-05 Thread Brian Topping

On Nov 5, 2010, at 4:15 PM, Martin Makundi wrote:

 We will provide a patch if possible. However, we might need some help
 onto our endevor.

If it's not possible, why would you expect someone else to do it?  Step up and 
make it happen!  Avoid the misunderstandings, show what it should do!

If you are demonstrating progress on something that benefits the community, I'm 
sure the help you find you need will materialize along the way.  

You have the faith in your convictions to insist that this is the right thing 
to do, and people who aren't interested just have fear of change.  What is 
holding you back?  A demonstration is far more valuable than a discussion.

Brian
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Really basic help...

2010-11-01 Thread Brian Topping
Adam,

If you are just getting started, models are one of the most important and 
underappreciated aspects of mastering Wicket.  It's really worth putting in the 
time up front to learn their nuances.

Have you checked out the excellent Wicket In Action book by Manning Press?  
It's one of those books that is worth the money if you value your time... 

Cheers, Brian

On Nov 1, 2010, at 12:52 PM, Igor Vaynberg wrote:

 it pulls that value out of its model, so check whatever object the
 model is pointing to.
 
 -igor
 
 On Mon, Nov 1, 2010 at 7:44 AM, adam.gibbons adam.s.gibb...@gmail.com wrote:
 
 Hi there!
 
 I'm extreamly new to Whicket, trying to put together my first sample
 application based on the AuthenticatedWebSession example.
 
 I have everything up and running nicely now, but I'd like to make a few
 simple changes.
 
 On the LoginPage, there are feilds for username, password and a check box
 for 'remeber me'.
 
 I want the username feild to be empty, but it always says support, I can
 not find anywhere in the code where this is set or any way to change it to
 something I want.
 
 In my page's constructor I can get the TextField object for the username
 feild using get(signInPanel:signInForm:username), but I don't see any
 methods for getting or setting the value...
 I'm sure i'm missing something very obvious!! Any help would be much
 appriciated!!
 
 Kind regards,
 Adam
 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Really-basic-help-tp3022249p3022249.html
 Sent from the Users forum mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Really basic help...

2010-11-01 Thread Brian Topping
As they say, a million monkeys on typewriters will eventually produce the 
works of Shakespeare.  :-)

I guess I'm lazy, to each his own.

On Nov 1, 2010, at 1:21 PM, Martin Makundi wrote:

 In my opinnion best way to learn is by trial and error ;)
 
 
 
 
 Not the most profitable way, though ;)
 
 **
 Martin
 
 2010/11/1 Brian Topping topp...@codehaus.org:
 Adam,
 
 If you are just getting started, models are one of the most important and 
 underappreciated aspects of mastering Wicket.  It's really worth putting in 
 the time up front to learn their nuances.
 
 Have you checked out the excellent Wicket In Action book by Manning Press?  
 It's one of those books that is worth the money if you value your time...
 
 Cheers, Brian
 
 On Nov 1, 2010, at 12:52 PM, Igor Vaynberg wrote:
 
 it pulls that value out of its model, so check whatever object the
 model is pointing to.
 
 -igor
 
 On Mon, Nov 1, 2010 at 7:44 AM, adam.gibbons adam.s.gibb...@gmail.com 
 wrote:
 
 Hi there!
 
 I'm extreamly new to Whicket, trying to put together my first sample
 application based on the AuthenticatedWebSession example.
 
 I have everything up and running nicely now, but I'd like to make a few
 simple changes.
 
 On the LoginPage, there are feilds for username, password and a check box
 for 'remeber me'.
 
 I want the username feild to be empty, but it always says support, I can
 not find anywhere in the code where this is set or any way to change it to
 something I want.
 
 In my page's constructor I can get the TextField object for the username
 feild using get(signInPanel:signInForm:username), but I don't see any
 methods for getting or setting the value...
 I'm sure i'm missing something very obvious!! Any help would be much
 appriciated!!
 
 Kind regards,
 Adam
 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Really-basic-help-tp3022249p3022249.html
 Sent from the Users forum mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Really basic help...

2010-11-01 Thread Brian Topping

On Nov 1, 2010, at 1:57 PM, Brian Topping wrote:

 As they say, a million monkeys on typewriters will eventually produce the 
 works of Shakespeare.  :-)

FWIW, http://en.wikipedia.org/wiki/Infinite_monkey_theorem describes what I was 
talking about here.  
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Really basic help...

2010-11-01 Thread Brian Topping

On Nov 2, 2010, at 12:31 AM, James Carman wrote:

 On Tue, Nov 2, 2010 at 12:11 AM, Brian Topping topp...@codehaus.org wrote:
 
 FWIW, http://en.wikipedia.org/wiki/Infinite_monkey_theorem describes what I 
 was talking about here.
 
 And I had already trained 5 monkeys to code Wicket.  I thought you were 
 serious!


Please don't create competition, I'm already having enough trouble keeping my 
job!


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-03 Thread Brian Topping
I personally use Wicket / Spring / JPA Hibernate / PostgreSQL.  Hibernate 
because I know how to tune it and I'm too busy learning other new technologies 
to focus on replacing one that is working for my needs now.  Spring because it 
helps immensely with unit testing and marginally by promoting good patterns 
(note these are two nice to have but not critical requirements for a small 
project).  I'd have to agree with the previous poster that Wicket is the one 
tried and true, money back guaranteed must have technology in the entire stack.

If you are just learning ORM for the first time, DataNucleus does look like a 
better way to go.

I would focus more on patterns and interfaces than on technologies.  Liberal 
use of patterns will keep your code honest and help you to refactor out or in 
technologies as necessary in the future.  Interfaces can always be extracted 
later, but having replaceable implementations are a huge benefit for migration 
between technologies.  You'll never get the perfect mix of technologies because 
they change all the time, but your application's domain focus will change very 
little.  The name of the game is to keep these realms as separate as possible.

One thing about Spring for a beginner is that you don't absolutely need it to 
get started with.  It's a big framework and it's core competency is dependency 
injection.  OTOH, the biggest thing it provides for small projects is a stable 
and well-maintained framework for database transactions.  If you want to use 
Spring, read the first chapter of the reference, skip to the database chapter, 
THEN skip back as necessary to fill in the gaps on how to set up the database.  
That's the fastest way to learn it.  Once you get started with it, the learning 
comes naturally.  If you use Spring, immediately learn the @SpringBean 
annotation in Wicket.

Good luck!

Brian

On Oct 3, 2010, at 7:40 PM, Francisco Diaz Trepat - gmail wrote:

 Hi I've tested wicket before it was in the apache incubator and found
 it to be awesome, since then we have adopted it and I have been
 migrating all legacy applications for my company for the last 3 years
 aprox.
 
 Now I have to build a small app to manage small accounting and
 logistics for my wife's Business
 
 She is opening a small printing shop for small business labels, such
 as wine bottle labels, clothing labels, bags, etc.
 
 At work I use wicket with an ingenious CORBA server, courtesy of the
 legacy applications.
 
 Now I am free to do whatever I want. This is the worst part. :-)
 
 I would like to help out and test maybe wicket 1.5 and some good
 database solution.
 
 Can you share some comments or recommendations on what to do?
 For Instance, I once read about Active Objects, I pretty much liked
 the idea and built some prototypes, but now the site is exactly the
 same and found their latest released is from 2008. So that is no so
 edgy...
 
 I don't wish to use hibernate, but could be some other object
 relational mapping, even hibernate if you insist... :-)
 
 So, ideas on what to use?
 
 UI = Wicket.
+ 1.4?
+ 1.5?
 middle layer?
 Persistence?
 
 Thanks in advance,
 f(t)
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-03 Thread Brian Topping

On Oct 3, 2010, at 11:19 PM, Jeremy Thomerson wrote:

 On Sun, Oct 3, 2010 at 9:17 PM, Brian Topping topp...@codehaus.org wrote:
 
 If you want to use Spring, read the first chapter of the reference, skip to
 the database chapter, THEN skip back as necessary to fill in the gaps on how
 to set up the database.  That's the fastest way to learn it.
 
 
 I've worked with Brian on other projects, and he is very good with
 architecture.  His advice here is sound. I would be curious just to be sure
 - which reference in particular do you mean?

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/
 is what I use.  I'm not ashamed to say that I still use this page frequently, 
as I'm less about memorizing everything and more about knowing where to look 
something up fast.  

As I started to think about documentation, Wicket In Action is a must have.  
Spring In Action is probably just as good, the folks at Manning would rather 
throw away a manuscript than release a bad one, but I haven't read it.  The 
paper versions are great to take to a cafe, but definitely spend a few extra 
bucks on the PDF too.  It's more than worth the price of a couple of lattes!
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-03 Thread Brian Topping

On Oct 3, 2010, at 11:58 PM, Sam Stainsby wrote:

 In any case coding to a standard persistence interface (JDO) 
 over a proprietary API is IMHO an insurance policy
 
 I can understand that, and I think that way too in some situations, but I 
 reject the notion that there is no price to pay.

This is where the old Total Cost of Ownership comes in to play.  The right 
technology for a particular developer or team is going to be the one that 
allows the problem domain to be solved with the least cost.  

For some developers, a lack of documentation or online examples is might cost 
more in lost time than the additional cost of laboriously setting up JPA and 
all the requisite annotations.  For others, unlearning their old habits might 
be a huge cost.  In a team environment, change can lead to politics, another 
cost.  As a project grows to include a team, potential difficulty in hiring new 
staff that is receptive to the chosen technologies also needs to be considered 
briefly (Wicket itself had this issue until recently).

There's *always* a cost, but which one is cheapest (most efficient, easiest to 
use, yada yada) in the end depends on a lot of localized factors.  If it did 
not, there would be a website that every developer visited before starting a 
new project, and the anointed best technologies for that moment would be 
listed there.  Heck, you would be able check boxes on the list and generate a 
POM from it...

Brian
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Java in CMS arena,..wicket to lead the way?!

2010-09-17 Thread Brian Topping

On Sep 17, 2010, at 2:04 AM, Arjun Dhar wrote:

 
 @Brian - 
 
 but there's a lot of fragmented development and not a lot of investment
 going back in. 
 --- yes, this is what I sense. I'm not even aware of the Brix community
 unlike Wicket which is more active. If you see the Brix architecture page i
 put some comments but Looks pretty dead which is pretty de-motivating.

One of the seeds that is missing from Brix is a good understanding of how 
things work internally.  Often, the people who can learn it with no 
documentation are such experienced programmers that they are either too busy 
with everyone asking them for something or they are not very good communicators 
(preferring to write more code).  Both of these mean when people learn how Brix 
works, it doesn't often translate into good code.

 
 I would challenge you to create needs in the core by demonstrating those
 needs 
 --- No, I dont think the core needs to be changed as such, Simple is better
  should remain preserved. However we can upgrade the Wicket dependencies
 from time to time? :) ?!

Hehe, yes.  The last time I looked for Jackrabbit in http://mvnrepository.com, 
it was still at 2.0.0, now it seems there are two newer versions in there.  
What I will do is do a release on what's in there, then go ahead and upgrade 
the dependencies on trunk so people can see if they like them.  I think we 
should release that too after people have had some time with it.

I would propose we start acting like an Apache project and taking votes on 
releases.  

 I ALSO like the idea it does NOT have a custom workflow etc built into core,
 coz I'm a fan of Drools work flow  Rules Engines to allocate business logic
 and workflows; Apache Camel  Spring Integration.

I'm also a fan of these projects, so I would *personally* have no problem 
integrating them, but we can't even collectively agree that OSGi is a good 
thing, so I'm sure that frameworks like these would never be unanimously 
received. :-)

On the other hand, abstracted interfaces with default implementations... that 
would be great.  

 
 If you are worried about people having access to your assets
 --- No sir, the more the merrier. I'd love to get into it once i'm sure to
 commit time  effort.
 
 From a using for commercial web sites perspective, issue is from a UI
 perspective the Admin module has a poor finish compared to Alfresco and say
 Hippo; its not just the CSS but the general layout sucks. ...I cant sell a
 website  present that to the customer without significant effort. Something
 I can look to contribute on.

I appreciate that.  But to defend whomever did that work, I don't design sites 
very well myself.  Maybe we could covert things to use a vertical accordion or 
something.  That's what I'm doing for my internal sites anyway...

 
 thank you.
 
 
 -- 
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Java-in-CMS-arena-wicket-to-lead-the-way-tp2541542p2543378.html
 Sent from the Users forum mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Java in CMS arena,..wicket to lead the way?!

2010-09-16 Thread Brian Topping
Have you thought about getting more involved with Brix?  

One of the great things about it is it isn't too centered on any one area.  It 
would be easy for you to help with a suite of plugins for doing the kind of 
stuff that you're talking about.  There are people on the Brix list that are 
talking about shopping carts right now, for instance.  Brix was originally 
designed for a company doing this kind of thing.  It's all possible, but 
there's a lot of fragmented development and not a lot of investment going back 
in.

Regarding the core, a lot of the features in core are going to be driven by 
needs in the plugins.  Hence, I would challenge you to create needs in the core 
by demonstrating those needs in the plugins.

Sometimes it's challenging on a small project to get the feedback that helps 
make development fun.  On the other hand, if the development isn't there, the 
community never grows to provide the feedback.

If you are worried about people having access to your assets, I'm sure you 
could find others that are working on things with the same feelings and you 
could start off privately.

Let's build some stuff!

Brian

On Sep 16, 2010, at 12:52 AM, Arjun Dhar wrote:

 
 Summary:: 
 This conversation is about Java in the CMS space, comparison to PHP and is
 there a future to reduce turn around time with Java. Are we as a community
 too elitist to be stuck on masturbating on frameworks rather than solutions
 that affect direct outcome? ..and then technically I've centered this around
 Brix  wicket.
 
 
 Hi,
 I've been exploring lot of Java CMS solutions and also frameworks. BRIX,
 Alfresco I feel are good for different reasons.
 
 From a Web framework point of view, I feel Wicket  I guess Sling  cut the
 mark pretty well (not much experience yet with Sling).
 
 However, with Java Community the solutions (beyond framework) finish is not
 comparable to the likes of PHP giants like Drupal, Wordpress etc. I operate
 in the small business market a lot , and this really hurts. I really feel
 the Java.
 
 With earlier version of Java it would get tedious and too boilerplate to
 produce anything quickly fast. But with the advent of scripting languages
 galore, be it Server JavaScript, Groovy, Scala ... and so many wonderful
 frameworks we have not taken it to the next level to producing quality CMS.
 
 Brix apparently will not be evolved further. which is fine; for its intent
 it does a good job but what about taking this to the next level. Also,
 problem with most CMS is they are content centric (ok hence they are called
 CMS) may seem dumb at a glance. 
 ..but I dont want my business model to go into a JCR repository. Perhaps the
 intent of the site is to reflect the actual product  business model in a
 neat way with WebDav. Lets call it PMS (hah) for lack of a better
 abbreviation. Also the ability to customize the admin module to give a
 Product centric view instead of Content centric view. This allows for
 greater analytic s and also then using java as an integration platform to
 integrate the business model with infinite things at the back end with
 pluggable extensions.
 
 I liked BRIX for many reasons. Am wondering if people are thinking about
 what I mentioned above ..also if we can take Brix further (not core) but by
 adding extensions and delivering a quality complete solution that could
 rival something like Drupal in the near future ...or maybe eventually!
 
 
 ..sorry i don't have my own Blog. You see WordPress is in PHP *wink hehe.
 Get the point?! :)
 
 
 -- 
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Java-in-CMS-arena-wicket-to-lead-the-way-tp2541542p2541542.html
 Sent from the Users forum mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: wicket-auth-roles and additional roles

2010-09-13 Thread Brian Topping
FWIW, I use Spring Security for everything I do in Wicket.  I was the original 
author of the Shiro-to-Wicket code on Wicket Stuff (somehow the attributions 
got lost in there), and if you don't need all the adaptors for stuff like LDAP 
(maybe Shiro has that by now), it's really worth looking at.

There's most of what you need for Spring Security in the Brix security example 
as well.

The first time I secured a Wicket app, I went through great pains to use 
someone else's framework.  But the fact is Wicket's security was designed by 
geniuses, so it's a snap to work with.  You really need to use a lot of 
features in Spring Security before it will save you time in the end.

On Sep 13, 2010, at 6:42 PM, James Carman wrote:

 If you want some example code for Spring Security, I can give you
 some.  It might save you some cycles.
 
 On Mon, Sep 13, 2010 at 6:41 PM, Mike Dee mdichiapp...@cardeatech.com wrote:
 
 Yes, you're correct.  I was just wondering if within wicket-auth-roles there
 were references to Roles.ADMIN or Roles.USER.  If there were, it could have
 been problematic.  Fortunately, there are none.
 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/wicket-auth-roles-and-additional-roles-tp2538164p2538173.html
 Sent from the Users forum mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: OT: Best practices regarding service layers DAOs

2010-08-30 Thread Brian Topping
This is a very good summary.  I would add one very important consideration that 
is not often obvious until far too late.

If you think you want to eventually use database transactions (and you're 
really missing out on a great thing not to use them), the service method 
interfaces that your view layer uses should *also* be transaction boundaries.  

Why?  

Mostly because frameworks like Spring will allow you to simply throw an 
exception from service layer code to have the transaction automatically rolled 
back.  It's transparent and super effective!

But there's a problem if your view code calls more than one write method in the 
service layer for a single view layer unit of work (such as a form submission). 
 If the first call succeeds and commits it's transaction and the second one 
fails, the second service method can't unroll the commit of the first.  

For this reason, I tend to model my service interfaces very closely to what 
happens in a single unit of work in the user interface.  

Thinking about transaction demarcations like this will take you a long way 
toward developing great service interfaces.

Cheers, Brian

On Aug 30, 2010, at 12:58 PM, Alexander Morozov wrote:

 
 Hi Sebastian,
 
 I think that service layer have to be responsible only for CRUD operations,
 but L(list) operations should be built upon JPA-specific _READ-ONLY_ queries
 or some kind of DSL (for example, querydsl
 http://source.mysema.com/display/querydsl/Querydsl). The last one point
 allows to build quite complex queries w/o affecting service layer.
 
 So we have:
 1. fine-graned business logic separated by service interface
 2. service interface implementation incapsulates CRUD-operation
 3. data provider uses specific service interface (in case of simple objects
 list) or query dsl
 
 Hopes it helps a little :)
 -- 
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/OT-Best-practices-regarding-service-layers-DAOs-tp2400408p2400436.html
 Sent from the Wicket - User mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: OT: Best practices regarding service layers DAOs

2010-08-30 Thread Brian Topping
While I haven't (yet) had this opportunity, I can't wait until the day that I 
wrap service interfaces with Web Services and connect it to a mobile UI.  

For that case alone, I focus my strategy on Spring managing the transaction 
with load-time weaving.  

$0.02...  

On Aug 30, 2010, at 10:31 PM, Alexander Morozov wrote:

 
 Brain thank you for comment,
 
 saying about Wicket and transactions, from my point of view, we have 2
 posibilities:
 1. manage transaction boundaries on per-request way (override
 RequestCycle.onBeginRequest(), RequestCycle.onEndRequest(),
 RequestCycle.onRuntimeException()) with PlatformTransactionManagement (do
 not forget to proper configure TM with
 SYNCHRONIZATION_ON_ACTUAL_TRANSACTION)
 2. propagate transaction by means of AspectJ and load-time weaving for
 actionable wicket subtypes (such as IFormSubmitListener, ILinkListener and
 etc.)
 
 -- 
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/OT-Best-practices-regarding-service-layers-DAOs-tp2400408p2400954.html
 Sent from the Wicket - User mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How to be a Top Wicket Developer

2010-07-22 Thread Brian Topping
I think it primarily comes from having a client that will push you to do things 
with it that you didn't think you could do before.  

Otherwise, you have to push yourself, and that takes a longer because people 
naturally avoid things that they aren't familiar with.

Note there are different types of Wicket developers.  If you want to work on 
the framework itself, it's a superset of the skills to be a great app developer 
using Wicket.  I personally have no shame in being a great Wicket developer who 
is very happy with what's there already.  But if you want to be a contributor 
to the framework, you're obviously going to have to have a vision for what you 
need and be able to package it in a way that others will find pleasing, and do 
so with a coding style that doesn't annoy the rest of the team members.  From 
my experience with other OSS projects, that's something that's better handled 
slowly and over time.  If someone was wondering what it takes to be a top 
framework developer, they probably don't have it yet, so I would focus first on 
creating great apps first, and back to getting some work where you can practice 
and be pushed to do things you haven't done before.

$0.02, YMMV, etc.

On Jul 22, 2010, at 11:33 AM, Nivedan Nadaraj wrote:

 Hi Guys
 
 This is off topic but how does one become a top developer for wicket? What
 do you think brings forth that talent and creativity?
 Cheers
 Niv


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Change from development to deployment mode in maven2

2010-07-19 Thread Brian Topping
Setting the JVM property is great because you can do it on your deployment 
server, so the same WAR runs in debug mode on all but the deployment machines.

If you want Maven to fix the setting on a build, you can create a properties 
file:

   wicket.configuration = ${deploy.type}

Then create one or more profiles in your pom, one of them set as a default 
profile.  In them, have Maven do a substitution on deploy.type for either 
'development' or 'deployment'.

Profiles are great for automated builds since the profile can be specified on 
the command line in the CI system.

Brian


On Jul 19, 2010, at 1:14 PM, Major Péter wrote:

 Hi,
 
 you could configure the wicket.configuration with JVM properties too, so
 you can have always enabled the production mode in web.xml, and override
 it with your dev server JVM property. See the JavaDoc for
 Application#getConfigurationType.
 
 Regards,
 Peter
 
 2010-07-19 19:10 keltezéssel, Gustavo Henrique írta:
 Hi!
 I'm using wicket in development mode but I need to change to deployment mode
 when maven is called. How I configure maven to change that mode when it is
 to generate war file?
 
 thanks!
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Getting started with Scala, Spring, Hibernate Wicket

2010-06-19 Thread Brian Topping
The best reason for me to keep a service/business layer talking to the DAO is 
to provide a clean transactional boundary.  Then, all I have to do is add a 
Spring @Transactional annotation to the method and I'm fully atomic.  

If my view logic is calling a half dozen DAO methods to effect an update, 
there's no way to have a single method demarcate the transaction.  Without a 
single method, no use of @Transactional, and I have to maintain complex 
transactional code by hand.  This is way more error prone and complex than 
taking (what are admittedly attractive) shortcuts to remove the service layer.

As a bonus, with well-defined service layer interfaces, I can easily generate 
SOAP or REST interfaces and expose them to other fat clients like mobile 
devices in the future.

On Jun 19, 2010, at 8:07 AM, James Carman wrote:

 Why do you have page - service - dao?  Why not just talk directly to
 the DAO for the getAll() method.  This level of indirection just
 causes more code (and confusion) in your simple example.  Is this just
 a best practice that you've devised?  I've never really understood
 folks' aversion to talking to the DAOs from the view layer, especially
 when it means you have to have duplicate methods in your service layer
 to do so.  It just doesn't make sense to me.
 
 
 On Sat, Jun 19, 2010 at 8:01 AM, James Carman
 ja...@carmanconsulting.com wrote:
 Why is spring-orm version 3.0.1.RELEASE and not 3.0.3.RELEASE?  Why
 not just uset a {spring.version} property in your POM so that it all
 stays in synch?
 
 On Sat, Jun 19, 2010 at 7:23 AM, Kent Tong k...@cpttm.org.mo wrote:
 Hi,
 
 I've written a tutorial on this topic. You may check it out at
 http://www.dzone.com/links/getting_started_with_scala_spring_hibernate_wicket.html
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Getting started with Scala, Spring, Hibernate Wicket

2010-06-19 Thread Brian Topping

On Jun 19, 2010, at 12:05 PM, James Carman wrote:

 On Sat, Jun 19, 2010 at 11:54 AM, Brian Topping brian.topp...@gmail.com 
 wrote:
 The best reason for me to keep a service/business layer talking to the DAO 
 is to provide a clean transactional boundary.  Then, all I have to do is add 
 a Spring @Transactional annotation to the method and I'm fully atomic.
 
 If my view logic is calling a half dozen DAO methods to effect an update, 
 there's no way to have a single method demarcate the transaction.  Without a 
 single method, no use of @Transactional, and I have to maintain complex 
 transactional code by hand.  This is way more error prone and complex than 
 taking (what are admittedly attractive) shortcuts to remove the service 
 layer.
 
 
 You can also annotate your Wicket pages/components methods with the
 @Transactional annotation if you use the AspectJ compiler.  They have
 to be public or protected in order for the compiler to pick them up
 and weave them I believe.  No big deal, in practice, really.

Sure, but AspectJ can be a machine gun in the hands of babes.  I try to avoid 
requiring team members be that qualified just to work on basic code.  Because 
once something like AspectJ is in the source base, it starts getting used, and 
before you know it, you have to start making solid experience with this new 
esoterica a hiring requirement.  Too expensive.

 
 As a bonus, with well-defined service layer interfaces, I can easily 
 generate SOAP or REST interfaces and expose them to other fat clients like 
 mobile devices in the future.
 
 
 Agreed, but having one method that merely delegates to another is just
 plain silly, IMHO.  You'd probably generate custom services that are
 tailored to the different view implementations so that you can
 aggregate things correctly for optimization purposes.

It's a pattern, and sticking with one pattern is very smart.  Especially 
because very few screens in a reasonably valuable application are only going to 
call a single DAO method.  It happens, but I'd question the value of the app at 
that point, and whether it needs transactions at all.  In that case, you are 
right, kill the service layer.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Best practises question

2010-05-18 Thread Brian Topping
It might even be interesting to have warnings like this as pluggable runtime 
libraries that users could download from wicket-stuff.  The idea is if a 
developer downloads and installs some of the libraries on their instance, they 
would get additional debugging output, and because they are in wicket-stuff, 
there's more opportunity for community participation.  

Maybe there's an SPI that uses AOP for the libraries to plug in with.

It's kind of like running 'lint' on the C compilers of yore, but with 
metadata-driven plugins that would be easy to share.

I bring it up because a client project I am working on has this problem all 
over the place.  It was something I knew had a solution, but along with a 
hundred other worst practices, it doesn't get solved quickly unless I happen to 
get hit over the head with the answer in a forum like this or while surfing.  
Installing a wicket lint superbundle would have given me a great log of 
problems and solutions, making both this app and the world of wicket apps that 
much more robust and appealing to new candidates.

Brian

On May 18, 2010, at 9:44 AM, James Carman wrote:

 Perhaps during development mode there should be a warning message if
 Wicket sees any fields on any components that are of type Page (or a
 subclass thereof)?  Or, even if the actual object is a page (the
 variable type could be some interface), it should spit out a warning
 telling you to use PageReference instead?
 
 On Tue, May 18, 2010 at 8:37 AM, Wilhelmsen Tor Iver toriv...@arrive.no 
 wrote:
 Well, I think that's quite obvious when you consider that each page is
 the root of a tree (not directed, acyclic graph) of components.
 Each component can have at most one parent.
 
 But you can pass a component to a different page/component without adding 
 it; like in the example of having a back link which wants a page to 
 navigate back to. If you keep that Page in an instance variable in the 
 back-from Page you will needlessly serialize that, too, unless you use a 
 PageReference.
 
 - Tor Iver
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket + security, what are the best options? Spring Security reached almost all the way...

2010-05-07 Thread Brian Topping
I recently updated the spring-security module for Brix to SS 3.0.1.  There's 
probably some nibbles in there for some of the more advanced kinds of security 
situations (like component-based authorizations against SS 3).  

http://code.google.com/p/brix-cms-plugins/source/browse/#svn/trunk/examples/example-springsecurity
 is the browsable source for the example project.

Check out Brix while you are there!

:B

On May 7, 2010, at 8:48 AM, PDiefent wrote:

 
 I have also problems integrating security into my Wicket project. I wanted to
 use simple authentication form the application server as I used many times
 before with JSF applications, but it didn't work.
 
 Spring security sounds very good, but since I don't use spring in my Wicket
 application I didn't manage to get the examples form above to work.
 
 It would be nice, if anyone could post a little example application as a
 kick start especially with Wicket 1.4.x
 
 Thanks, Peter
 -- 
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Wicket-security-what-are-the-best-options-Spring-Security-reached-almost-all-the-way-tp2068415p2134111.html
 Sent from the Wicket - User mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: http://cwiki.apache.org/WICKET is down

2010-04-10 Thread Brian Topping
Yes, I saw that too.  Apache infrastructure was attacked this week, I presume 
they are working on repairing things right now.

On Apr 10, 2010, at 2:00 PM, Carlos Chávez wrote:

 Hello everyone.
 
 I just want to let all know that the wiki is seems down,
 can anyone confirm this ?
 
 I understand the wiki is on http://cwiki.apache.org/WICKET
 
 --
 Cheers.
 Carlos Chávez.
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org