date:20080127

Re: Label is driving me a little crazy

2008-01-27 Thread Andy Czerwonka

Did something change in 1.3?

http://wicketstuff.org/wicket13/compref/?wicket:bookmarkablePage=%3Aorg.apache.wicket.examples.compref.FormPage

This simple example doesn't work for me either.  I get a
1. [MarkupContainer [Component id = feedback, page = 
ca.arcticpenguin.mff.NewListingPage, path = 
0:newListingForm:feedback.FeedbackPanel, isVisible = true, isVersioned = 
false]]I don't understand how a simple example is not working.  I'm copying 
http://wicketstuff.org/wicket13/forminput/ and again, issues rendering the 
labels.  It comes from the property file, and I'm assuming the properties 
file is automatically hooked up given I don't see any code that references 
it.
Erik van Oosten [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 Try removing the id attributes from the markup. Wicket likes to generate 
 this for itself.
 You'll also need to add a FormLabel (or something named like that) to the 
 for element.

 Regards,
 Erik.


 Andy Czerwonka wrote:
 I found this thread:

 http://www.mail-archive.com/users@wicket.apache.org/msg04400.html

 I have written similair code, but I'm getting an exception.  Clearly my 
 markup is wrong, but I can't for the life of me unnderstand why?  When I 
 inspect the code, the page contains the right things.  I'm a wicket 
 newbie to be sure, so apologies if it's a silly question.

 Here's the java snippet (similair to the java on the above thread)

 private void buildForm() {

 RequiredTextField nameTextField = new RequiredTextField(name);

 nameTextField.setLabel(new Model(Business Name));

 add(nameTextField);

 addFieldLabel(this, nameTextField);

 add(new Button(saveButton));

 }


 protected FormComponentLabel addFieldLabel(final MarkupContainer 
 container, final FormComponent formComponent) {

 SimpleFormComponentLabel label = new 
 SimpleFormComponentLabel(formComponent.getId() + Label,

 formComponent);

 container.add(label);

 return label;

 }

 The markup is as follows:

 form wicket:id=newListingForm action=save

 fieldset

 label for=name wicket:id=nameLabel 
 id=nameLabel[nameLabel]/label

 input wicket:id=name id=name type=text size=50 /

 input type=submit wicket:id=saveButton value=save /

 /fieldset

 /form

 The error looks like:

 1. [MarkupContainer [Component id = nameLabel, page = 
 ca.arcticpenguin.mff.NewListingPage, path = 
 0:newListingForm:nameLabel.SimpleFormComponentLabel, isVisible = true, 
 isVersioned = false]]






 -
 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: Wicket Security - runtime ACLs and Groups help plz

2008-01-27 Thread Maurice Marrink

There is no example application (that i know of) showing what you want.
Let me recap what i think you want:
You have an application (probably with a basic set of roles)
You want to add plugins (probably containing several pages each
requiring there own special permissions to do stuff)
The extra permissions for the plugin need to be picked up dynamically
from the plugin itself.

This is certainly more complex than what we typically use in our
applications but i think i have an idea of how i would approach this:

My choice would be to use swarm as it is designed to be flexible.
First off i assume you have some kind off registry for you plugins so
that your applications knows what is available. and that they have
some kind of life cycle (init, destroy).
It should not matter much if new plugins are installed while the
application is running or not.

Normally i would store my principals in the database and the
permissions for each principal are stored in the ACL file. This has
the advantage that i can use the principals to build dynamic roles
(also stored in the database) and easily maintain a hierarchy between
my principals ( meaning if i grant principal A i automatically get
principal B).
It isn't that difficult to replace the acl file with an acl database
but it means your plugin is then depending on something external
instead of everything being contained in the plugin jar.
If you don't care about external dependencies you can go ahead and do
this, if however you want the plugin to be self contained and don't
want anything remaining after you have removed the plugin you could
try the following:
Since principals are uniquely identified by there class and name you
can use just those as reference in your roles instead of foraign keys.
The roles can be stored in the database without problems.

I have mentioned permissions, principals and roles lets see how that
picture fits together:
Users are granted roles, a role is nothing more then a set of
principals. Principals are dictated by the system, roles can be
created dynamically by users (application manager usually) and new
roles will need to be created and assigned to users after a plugin has
become available. You could have the plugin create a set of default
roles but they still need to be assigned to users.
A principal is a set of permissions, permissions are hardcoded in your
acl. the same permission might apply to several principals.

So what happens if the system detects a new plugin:
The plugin exposes the location of the extra acl, the system then
reloads the acl, adding the extra location. the appropriate life cycle
events of the plugin are triggered allowing it if necessary to create
the required entries in the database.
The system then continues its normal operation.

To summarize, this is what i would do in a situation like this:
-Each plugin has there own acl file containing the standard swarm
permissions (ComponentPermission and optionally DataPermission) and
maybe some of your own permissions.
-The plugin either defines there own Principal class or uses the one
from the application.
-Principals are only referenced by class and name, not stored in a database.
-The application defines a set of default Roles.
-Roles are stored in a database and contain a set of Principals.
-Roles can be dynamically created by selecting one or more of the
available Principals.
-When installing a new plugin the Hive (swarm acl) needs to be
reloaded so the acl file from the plugin can be added.

Let me know if this comes close to what you wanted and if it helps you or not.

Maurice

On Jan 27, 2008 2:34 AM, Ned Collyer [EMAIL PROTECTED] wrote:

With wicket security (either wasp/swarm, or wicket-auth-roles) can things
like Roles and Permissions be created through a web interface?

Eg,
I need a system whereby I can add new roles (or principals) through the web
interface, and define their permission to a ACLs which are determined by
which which plugins the system is configured to use.

Each plugin will implement some interface, and expose the ACLs that it has
available. - these will not be manually configured, and should not require
any java code change when I add a plugin to the system.

I'm having trouble mapping this to either swarm or wicket-auth-roles. (and
trouble explaining it well ;))

I believe wicket-auth-roles is more component oriented, but reading about
this stuff makes my head swim.

Can anyone either steer me in the right direction, or point at an example
that gets these ACLs and roles from a datastore at run time.
--
View this message in context:
http://www.nabble.com/Wicket-Security---runtime-ACLs-and-Groups-help-plz-tp15115011p15115011.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]

client side validation

2008-01-27 Thread Ryan Sonnek

http://www.jroller.com/wireframe/entry/wicket_client_side_validation

I've spent the past couple weeks investigating Wicket's support for
client side validation.  IMO, using Ajax for validation in Wicket is
really amazing.  Lots of folks are touting javascript validation
right now, but I think Wicket has a definite advantage because the
Ajax validation *reuses* all of your server side validation for free!
This might be worth mentioning on the feature list somewhere and I'd
be interested in any comments.

Ryan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Page Expired when going back to an ajax page

2008-01-27 Thread Andrew Williams


I have a peculiar problem that I hope can be solved by the experts!

I have on my application pages a panel that is updated using an  
AbstractAjaxTimerBehavior to update the style attribute making it  
visible or not.
This works just fine on the current page. If, however, I press the  
back button in the browser to show a page that is no longer in the  
current session this problem occurs:


After the time of the ajax timer passes the request is sent for the  
panel update and the whole page is replaced by the standard Page  
Expired exception page.


Is there a way to change this behaviour so it simply does not update  
instead of causing this exception to be thrown?


Many thanks in advance,
Andrew

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Strange Sql exception accesing Wicket page

2008-01-27 Thread Johan Compagner

that looks like a database pool, where connections are in and after a while
a specific connection isn't used for a long time and oracle terminates or
makes in invalid.

configure your database pool that way that you test the connection before it
gives you the connection

johan



On Jan 26, 2008 9:47 AM, [EMAIL PROTECTED] wrote:

 Hello:
 I have several bookmarkable links that would bring up page with data
 retrieved from database via JPA/TOPLINK (EntityManager is always created
 fresh evertime data is retrieved).  The servlet session time is 30 minutes
 but after several days when accessing some links, I got this
 WicketMessage: Error attaching this container for rendering .
 Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2006.8 (Build
 060830)): oracle.toplink.essentials.exceptions.DatabaseException
 Internal Exception: java.sql.SQLException: ORA-02396: exceeded maximum
 idle time, please connect again
 Error Code: 2396
 It appears that somewhere the page object is still holding on something
 causing this. After a few repeated clicking of browser refreshing button,
 the error would go away and a normal page is displayed without any other
 intervention. I'd think after a few days, all session related page
 objects would be no factors and it would work like the first time ever
 accessing it. Maybe I have problem with my jpa setup but I used similar
 methods under Seam(no EJB3) without issues so I think there maybe some
 issues with page caching?
 Thanks

44 matches

Mail list logo