Re: New Extensible Autocomplete - Attaching a new JIRA to have a code review
Nice work. It's pretty amazing how easy it is to create these "widgets" with wicket. One comment i have is that the scriptaculous autocomplete component supports "custom layouts" where you can display any any html for each autocomplete result. It also supports the concept of a "key/value". you can have any value posted back to the server, but it can display something different. I'm sure your usecase is different enough to warrent another contribution. Just wanted to mention that a widget already exists for a "similar" usecase. Ryan On 7/24/07, Francisco Diaz Trepat - gmail <[EMAIL PROTECTED]> wrote: Hi, igor, or someone: I took the liberty in writing an extensible autocomplete behavior based on the AutocompleteTextField by Janne (jannehietamaki). I was supposed to open a JIRA but as I've never done this, I wanted to get some instructions on how to do it. For those not following. The idea is to have an autocomplete behavior that allows you to have *key* and *value* if you need it. This is done by either including a hidden field or by adding an attribute to the autocomplete-field, or it can be left out and works exactly like the one that is know available in the extensions package. The thing started out as the current implementation used a fixed "node path" to get the elements that needed to render select etc. Now it uses an option/choice name. To do this I had to re-write the JavaScript and All the abstract classes so I did a new package all together. And renamed all of the classes to have both of them without any conflicts. I also included a new collection class in the javascript to help out and I putted on a Wicket.Collection "package", and also named this autocomplete as ExtensibleChoiceAutocomplete. *Extensible* because you can put in it any html markup you feel like and it will work (choose arrows etc), *Choice* because it can use key and value like a DropdownChoice, and *Autocomplete* because it is an autocomplete. All naming convention might be wrong and some of my code might not make the grade for you guys, so what I would like is to have someone review it and see if it is considered to be included somewhere. Wicket is awesome, I get lots of help all the time, and just want to contribute. There are some algorithms in the JavaScript that didn't worked on IE 7 and IE 6 because of a well known issue on IE that is that it does not refresh document DOM on the assignment of the innerHTML property of an element. But that is taken care of by using element.all collection that works for IE 7 and 6. Also my code is usually considered heavily commented so as I see wicket code in general is not, maybe the reviewer would have to erase some comments. Feel Free is the key. I want to contribute, keep contributing in the future, and learn a proper way not to step on any one's feet. Best regards, f(t)
Re: New Generic Autocomplete (contribute?)
hmmm...seems like a bug to me. i'll look into it. On 7/17/07, Francisco Diaz Trepat - gmail <[EMAIL PROTECTED]> wrote: The wicket-scriptaculous sample throws the following exception due to a AbstractAutocompleteBehavior.js that is not present in the wicket-scriptaculous. I have svn the last version known. I don't know I'll try with the user list. WicketMessage: Exception in rendering component: [MarkupContainer [Component id = -header, page = test.wicket.autocomplete.pages.ScriptaculousAutocomplete, path = 0:- header.HtmlHeaderContainer, isVisible = true, isVersioned = true]] Root cause: java.lang.IllegalArgumentException: resource AbstractAutocompleteBehavior.jsnot found for scope class org.wicketstuff.scriptaculous.autocomplete.AbstractAutocompleteBehavior(path = org/wicketstuff/scriptaculous/autocomplete/AbstractAutocompleteBehavior.js) at org.apache.wicket.util.template.PackagedTextTemplate.( PackagedTextTemplate.java:167) at org.apache.wicket.util.template.PackagedTextTemplate.( PackagedTextTemplate.java:135) at org.apache.wicket.util.template.PackagedTextTemplate.( PackagedTextTemplate.java:118) On 7/16/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > I'd be interested to know if you had any issues using the > wicket-scriptaculous autocomplete component? > > On 7/16/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > On 7/16/07, Francisco Diaz Trepat - gmail < > [EMAIL PROTECTED]> > > wrote: > > > > > > I think a new form of autocomplete is needed. One that could better > > > abstract > > > scenarios in which user don't want to use the UL LI elements. > > > > > > I plan in developing one, if the boss approves, and wanted to know if > I > > > can > > > send it to some of you so you 'll review it and see if I can > contribute > > > some > > > to the cause... ;-) > > > > > > create a jira and attach a patch > > preferably what you do is hack up the existing one instead of starting > > from > > scratch. > > > > -igor > > > > > > f(t) > > > > > >
Re: New Generic Autocomplete (contribute?)
I'd be interested to know if you had any issues using the wicket-scriptaculous autocomplete component? On 7/16/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: On 7/16/07, Francisco Diaz Trepat - gmail <[EMAIL PROTECTED]> wrote: > > I think a new form of autocomplete is needed. One that could better > abstract > scenarios in which user don't want to use the UL LI elements. > > I plan in developing one, if the boss approves, and wanted to know if I > can > send it to some of you so you 'll review it and see if I can contribute > some > to the cause... ;-) create a jira and attach a patch preferably what you do is hack up the existing one instead of starting from scratch. -igor f(t) >
Re: Problem with latest changes in FormComponent:validate()
Jan, Just wanted to follow up with on this. If you're looking for tight integration of wicket with hibernate annotations, please check out the wicketstuff-hibernate project. I really think this would work well for you. You've obviously been working in this area for a while, so if there are any things you can recommend for the wicketstuff-hibernate project that would help your project, let me know. http://jroller.com/page/wireframe/?anchor=hibernateannotationcomponentconfigurator Ryan On 7/3/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote: Thanks for adding the 'INullAcceptingValidator'. This solves our problem in a clean way. Just a small suggestion: I've seen that the CompoundValidator does not implement this interface. Would it not be correct to assure that the CompoundValidator is called always, and that the same logic of checking the implementation of the interface is applied to all the validators in the chain ? Jan. -- View this message in context: http://www.nabble.com/Problem-with-latest-changes-in-FormComponent%3Avalidate%28%29-tf3945885.html#a11410534 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Drag and drop
You might want to check out wicketstuff-scriptaculous. There's a DraggableBehavior that's built on the excellent scriptaculous javascript library. On 6/21/07, Sean Sullivan <[EMAIL PROTECTED]> wrote: Thanks Martijn. How does an application developer use Wicket.Drag?Will there be a DraggableBehavior (IBehavior) object? Sean On 6/21/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > The benefits of unix: > > find jdk-1.4/wicket -name "*.js" | xargs grep -E "rag|rop" > > delivers jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket- > ajax.js > > > Martijn > > > On 6/22/07, Sean Sullivan <[EMAIL PROTECTED]> wrote: > > Is there drag/drop code in svn.apache.org? Where? > > > > > > > > On 4/7/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > > > > > In our review by the IPMC a questions has popped up on our drag/drop > > > library. I tried to find the exact license, but couldn't find it: > > > creative commons 2.0 is very ambiguous at best. > > > > > > Searching for the js library brought me to dynamic drive [1] and it > > > has the following license for all js files on their site [2]. In short > > > we are not allowed to package the dom-drag.js file with Wicket under > > > those terms. > > > > > > Couple of questions: > > > - how did we find out it was distributed under the CC 2.0 license > > > (dynamic drive doesn't have that in the mentioned file) > > > - which CC 2.0 license is meant? > > > - can we replace it with something ASL compatible? > > > - can we get a new license from the author (he must be in a good > > > mood, he's engaged and all [3])? > > > > > > I've created a JIRA issue (WICKET-448) for this [4]. > > > > > > Martijn > > > > > > [1] http://www.dynamicdrive.com/dynamicindex11/domdrag/ > > > [2] http://www.dynamicdrive.com/notice.htm > > > [3] http://www.youngpup.net/2007/03/engaged.html > > > [4] http://issues.apache.org/jira/browse/WICKET-448 > > > > > -- > BREAKING NEWS: Wicket joins the Apache Software Foundation as Apache > Wicket > Join the wicket community at irc.freenode.net: ##wicket > Wicket 1.2.6 contains a very important fix. Download Wicket now! > http://wicketframework.org >
Re: [announce] Apache Wicket
A well deserved congratulations go out to all of the team! I'd love to buy you all a round of beers (or the drink of your choice)! =) On 6/20/07, Mark Derricutt <[EMAIL PROTECTED]> wrote: Congrats ;-) On 6/21/07, Maurice Marrink <[EMAIL PROTECTED]> wrote: > > Congratulations to everyone for making Apache Wicket a success. >
Re: custom dependencies on bamboo
not sure how you got this to work. the repository you specified does not have a jar available for the jta dependency. http://repo.mergere.com/maven2/javax/transaction/jta/1.0.1B/ just the POM is uploaded. On 6/19/07, Maurice Marrink <[EMAIL PROTECTED]> wrote: That is weird because the jar is definitely available on that repo. could it be your dependency is incorrect? The before mentioned repository and this dependency javax.transaction jta 1.0.1B compile work for me. Or is there perhaps an inherited dependency by another jar? in that case you could try running maven with mvn help:effective-pom and if needed exclude some dependencies. for example org.springframework spring-mock 1.2.3 jar test org.springframework spring More helpful command line options can be found here http://jan.vegetband.cz/en/maven2-127.html Maurice On 6/19/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > No luck. Still get the same error. > > I think i'll look into adding the jta dependency to my own public repo: > http://maven.codecrate.com/ > > > On 6/19/07, Maurice Marrink <[EMAIL PROTECTED]> wrote: > > > > If you add the following repository to your pom, you won't need to > > install it locally. > > > > mergere > > Mergere Maestro Repository > > http://repo.mergere.com/maven2 > > > > > > Maurice > > > > On 6/19/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > Lovely maven repositories... > > > > > > I'm trying to enable a hibernate build on the wicketstuff bamboo server, > > and > > > I get this wonderful error. Can we manually install this jar to get the > > > build up and going? > > > > > > [INFO] > > > > > > [ERROR] BUILD ERROR > > > [INFO] > > > > > > [INFO] Failed to resolve artifact. > > > > > > Missing: > > > -- > > > 1) javax.transaction:jta:jar:1.0.1B > > > > > > Try downloading the file manually from: > > > http://java.sun.com/products/jta > > > > > > Then, install it using the command: > > > mvn install:install-file -DgroupId= javax.transaction-DartifactId=jta > > > \ > > > -Dversion=1.0.1B -Dpackaging=jar -Dfile=/path/to/file > > > > > >
Re: custom dependencies on bamboo
No luck. Still get the same error. I think i'll look into adding the jta dependency to my own public repo: http://maven.codecrate.com/ On 6/19/07, Maurice Marrink <[EMAIL PROTECTED]> wrote: If you add the following repository to your pom, you won't need to install it locally. mergere Mergere Maestro Repository http://repo.mergere.com/maven2 Maurice On 6/19/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > Lovely maven repositories... > > I'm trying to enable a hibernate build on the wicketstuff bamboo server, and > I get this wonderful error. Can we manually install this jar to get the > build up and going? > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > Missing: > -- > 1) javax.transaction:jta:jar:1.0.1B > > Try downloading the file manually from: > http://java.sun.com/products/jta > > Then, install it using the command: > mvn install:install-file -DgroupId=javax.transaction-DartifactId=jta > \ > -Dversion=1.0.1B -Dpackaging=jar -Dfile=/path/to/file >
custom dependencies on bamboo
Lovely maven repositories... I'm trying to enable a hibernate build on the wicketstuff bamboo server, and I get this wonderful error. Can we manually install this jar to get the build up and going? [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) javax.transaction:jta:jar:1.0.1B Try downloading the file manually from: http://java.sun.com/products/jta Then, install it using the command: mvn install:install-file -DgroupId=javax.transaction -DartifactId=jta \ -Dversion=1.0.1B -Dpackaging=jar -Dfile=/path/to/file
Re: [Wicket-user] inspecting model from IComponentInstantiationListener
Even if the common logic was abstracted into an abstract class, you still have to update every model in the application to use this new abstract model. This is a much more expensive change than registering an component instantiation listener. also, your assuming you can have *one* abstract model that satisfies *every* usecase. Realistically, you'll have to recreate a large number customized models (Coumpound, Property, Nested, etc). this is a real PITA. On 5/13/07, Johan Compagner <[EMAIL PROTECTED]> wrote: But where are you testing it up with your ComponentInstantationListener?? If it really has to be for every model. Then you could have a common base class or just attach it auto on every (Form)component? johan On 5/13/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > On 5/13/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > but that can't be done on instantiation because you have no idea when > the > > model is set. > > also you can have inhertiable models and so on. > Understood. That's why i need a "new" hook instead of onInstantiated() > > > But you want to do something when it has a specific model? > > That can already be done > > Let the model implement IComponentAssignedModel then you get a call: > > wrapOnAssignment > > just return this (that should work) and do you thing on the component > you > > get > Okay, well that's a start. The downfall with this approach is that > you have to change *every* model in the system to use this interface. > The reason for using the ComponentInstantiationListener is to make > *sweeping* application wide changes in one spot. > > my current app is relatively small, so it's not that big of a deal. > But the hibernate component instantiaion listener is useless without > this new hook. >
Re: Code Freeze for RC?
Although I'm not a core developer, since I was involved in bringing
this topic up, i'll just throw my 2 cents out there.
This is definately not a showstopper for me, and I would rather see
wicket 1.3 get out the door. This issue is more of a long term design
decision and shouldn't be rushed.
On 5/13/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
I'd like to propose that we either wrap this up immediately (next
day or two) or simply not fix this for 1.3. We need to get an RC
out there as soon as possible.
Eelco Hillenius wrote:
>
> We have a bit of a stalemate currently in how we'll support validators
> that are or contribute behaviors.
>
> First, why would we want such behaviors? It is to enable validators to
> influence what is rendered so that they can e.g. set a maxlength
> attribute, add client side javascript validation, or even add ajax
> validation (or a combination of these).
>
> For example:
>
> private static class MaxLengthValidator extends
> StringValidator.MaximumLengthValidator
> implements
> IBehaviorProvider
> {
> public MaxLengthValidator(int maximum)
> {
> super(maximum);
> }
>
> public IBehavior newValidationBehavior(Component component)
> {
> if (component instanceof AbstractTextComponent)
> {
> return new SimpleAttributeModifier("maxlength",
> String.valueOf(getMaximum()));
> }
> return null;
> }
> }
>
> The current implementation is based on interface IBehaviorProvider:
>
> /**
> * Validator that provides a behavior, e.g. for rendering client-side or
> ajax
> * validation. This interface can be implemented by either
> * [EMAIL PROTECTED] IValidator validators} or [EMAIL PROTECTED]
IFormValidator form
> validators}.
> */
> public interface IBehaviorProvider extends IClusterable
> {
> /**
>* Gets behavior for validation. This method is called right after the
>* validator is added to a form or form component. The resulting
behavior
>* will be added to the component. Note that after the behavior is
added,
> it
>* will just lead its own life; this method will not be invoked anymore.
>*
>* @param component
>*component currently using the validator
>* @return The behavior, which can be used for rendering e.g. javascript
> or
>* ajax validation. If this returns null, it will be ignored.
>*/
> IBehavior newValidationBehavior(Component component);
> }
>
> which is an optional interface your validators can implement if they
> want to contribute such behaviors.
>
> Now Igor in particular has a problem with this solution as he likes
> the alternative (which I actually implemented at first, but didn't
> commit) where you can simply code classes that are both a validator
> and a behavior (implement IValidator or IFormValidator and IBehavior).
>
> The technical issue with that is that we have an add method for both,
> while they have a different hierarchy, so unless you do a hard cast,
> it's not going to work. And even if you do a hard cast, behaviors and
> validators are currently stored in their own structures, so either the
> add methods would have to be aware that a behavior can also be a
> validator (detail: validators currently are only known by form
> components, so add(IBehavior) would have to do some instanceof
> checking on itself to get this working) and that a validator can be a
> behavior in the add(I(Form)Validator) method.
>
> A way to fix this is to create a common interface (in my
> implementation I called this IComponentFacet) for IBehavior and
> IValidator and have one add method. In the mechanism I implemented,
> facets were stored in the same structure (so the validators field in
> FormComponent was removed) and it worked with a lookup method like
> getFacets(Class).
>
> The problem with this though is that once we start thinking in this
> direction, it opens up a whole new range of questions. For instance,
> what happens when people add validators to non-form components? Is
> 'detachable' or 'onBefore/AfterRender' really only something for
> behaviors? What kind of mixing and matching can we expect people to
> try in the future? I guess my largest problem is that I don't have a
> great feeling about this mixing conceptually. I think in a future
> version of Wicket, we might improve components by decoupling parts of
> it so that you can assemble the parts you need. If and only if that
> would really be worth the increased complexity of the API that comes
> with such a change. However, I'm afraid that by supporting a kind-of
> mixin like a combined validator and behavior is a step in that
> direction, but it's too soon, half baked (like Jonathan stated on IRC,
> we
Re: [Wicket-user] inspecting model from IComponentInstantiationListener
On 5/13/07, Johan Compagner <[EMAIL PROTECTED]> wrote: but that can't be done on instantiation because you have no idea when the model is set. also you can have inhertiable models and so on. Understood. That's why i need a "new" hook instead of onInstantiated() But you want to do something when it has a specific model? That can already be done Let the model implement IComponentAssignedModel then you get a call: wrapOnAssignment just return this (that should work) and do you thing on the component you get Okay, well that's a start. The downfall with this approach is that you have to change *every* model in the system to use this interface. The reason for using the ComponentInstantiationListener is to make *sweeping* application wide changes in one spot. my current app is relatively small, so it's not that big of a deal. But the hibernate component instantiaion listener is useless without this new hook.
Re: inspecting property models
On 5/12/07, Johan Compagner <[EMAIL PROTECTED]> wrote: But it is not the same anyway you can't call getTarget().getClass() that is at least not the class of the property that can never be Person.Address.Street (street is a string) what is the target? Street? but that can be null because it is not set yet or is the target Address? Because thats the target where you call setStreet(String) on but then the class is not the properties class. I understand the model can be null. If that's the case, I'm SOL anyways. Nested property models are tricky, but for right now I really don't care about them. It's more of an edge case and isn't the main use case I'm trying to work with.
Re: [Wicket-user] inspecting model from IComponentInstantiationListener
http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/src/main/java/org/wicketstuff/hibernate/HibernateAnnotationComponentInstantiaionListener.java?revision=2135&view=markup If you look at the source, it should be a little easier to follow. I'm trying to register a listener that inspects the models of *all* components that will automatically register validators for that component. On 5/12/07, Johan Compagner <[EMAIL PROTECTED]> wrote: what do you want to do there? isn't that something for an IAuthorizationStrategy ? johan On 5/12/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > I'm proposing adding a method to the IComponentInstantiationListener > (or a new interface) that would be invoked when a components model is > bound/attached/whatever. > > I'd like to register a component listener that listens to every > component in my application and can configure it appropriately (by > inspecting the model and it's annotations). > > Please let me know if this isn't really a good direction for wicket, > and if there should be a different way to do this. Thanks. > > Ryan > > On 5/11/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > On 5/11/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > What exactly should a component instantiation listener be able to do? > > > I'm trying to build one that will inspect the model of every > > > component, but the model is not yet bound. is there a way to register > > > a listener that is notified once the model is bound? > > > > There is none currenlty. Though I can imagine one. If you can argue a > > good use case, you could propose this on the dev list. > > > > Eelco > > > > > - > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > ___ > > Wicket-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > >
Re: [Wicket-user] inspecting model from IComponentInstantiationListener
I'm proposing adding a method to the IComponentInstantiationListener (or a new interface) that would be invoked when a components model is bound/attached/whatever. I'd like to register a component listener that listens to every component in my application and can configure it appropriately (by inspecting the model and it's annotations). Please let me know if this isn't really a good direction for wicket, and if there should be a different way to do this. Thanks. Ryan On 5/11/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: On 5/11/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > What exactly should a component instantiation listener be able to do? > I'm trying to build one that will inspect the model of every > component, but the model is not yet bound. is there a way to register > a listener that is notified once the model is bound? There is none currenlty. Though I can imagine one. If you can argue a good use case, you could propose this on the dev list. Eelco - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: inspecting property models
On 5/11/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Why limit to getTargetClass() when its possible to return with getTarget() > and do a getTarget().getClass() ? I agree with Eelco. There's nothing "wrong" with exposing the target and then calling getClass(), it's just not what I needed. I didn't here anyone else chime in on what they needed for inspecting models...
Re: poll: validators and behaviors combined... contribute or IS-A?
The more I think about this, the more I think that a Validator IS-A Behavior. Here's why: * wicket has a very robust behavior infrastructure. The validation framework is (intentionally) very minimalist * there are a *million* other java libraries that do validation. If wicket wants to promote it's own validation library, it needs to be broken out as a separate project altogether. I think it would be best for IValidator to extend from IBehavior. That way, any validator can *choose* to perform like a behavior as well. This removes the need for separate add(Behavior) and add(Validator) methods. The FormComponent can loop through the behaviors and do an instanceof check to see if the Behavior is a Validator. Again, I don't see this as bloating the Validator framework. Since there are so many validation frameworks out there, I use wicket for my web project, not for end-to-end validation. On 5/11/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote: On 5/11/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Now Igor in particular has a problem with this solution as he likes > the alternative (which I actually implemented at first, but didn't > commit) where you can simply code classes that are both a validator > and a behavior (implement IValidator or IFormValidator and IBehavior). Long term, I think this is the "correct" solution as well. I do agree with your points though that this leads to a more "sweeping" change that affects a lot of the core framework. > The technical issue with that is that we have an add method for both, > while they have a different hierarchy, so unless you do a hard cast, > it's not going to work. And even if you do a hard cast, behaviors and > validators are currently stored in their own structures, so either the > add methods would have to be aware that a behavior can also be a > validator (detail: validators currently are only known by form > components, so add(IBehavior) would have to do some instanceof > checking on itself to get this working) and that a validator can be a > behavior in the add(I(Form)Validator) method. Yuk. If they "really" share a common interface, their should not be two separate "add" APIs. overloading the add method for two very different purposes is a very bad idea IMO. I think this should be changed regardless of this new feature. > A way to fix this is to create a common interface (in my > implementation I called this IComponentFacet) for IBehavior and > IValidator and have one add method. In the mechanism I implemented, > facets were stored in the same structure (so the validators field in > FormComponent was removed) and it worked with a lookup method like > getFacets(Class). I agree with Al that seeing an IDE autocomplete a "Facet" instead of "Behavior" or "Validator" is a really big deal. I don't think it's worth it right now. > I guess my point is made. I'll back off for a bit and see what other > people have to say about this. Anyone's opinions are welcome, and core > developers, please contribute so that we can make this decision in > consensus. KISS. Keep It Simple (Stupid) :) The current solution is simple, but I thought there were objections because the Validator API is fairly independent of the internal wicket? I know you have to use this new optional interface, but it makes perfect sense for some of the core wicket validators to start using this feature ASAP. The max-length validator is a perfect example where this feature is needed. Start small, and don't try to support every usecase. IMO, getting the ball rolling with the max-length validation is a great start. Ryan
Re: poll: validators and behaviors combined... contribute or IS-A?
On 5/11/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Now Igor in particular has a problem with this solution as he likes the alternative (which I actually implemented at first, but didn't commit) where you can simply code classes that are both a validator and a behavior (implement IValidator or IFormValidator and IBehavior). Long term, I think this is the "correct" solution as well. I do agree with your points though that this leads to a more "sweeping" change that affects a lot of the core framework. The technical issue with that is that we have an add method for both, while they have a different hierarchy, so unless you do a hard cast, it's not going to work. And even if you do a hard cast, behaviors and validators are currently stored in their own structures, so either the add methods would have to be aware that a behavior can also be a validator (detail: validators currently are only known by form components, so add(IBehavior) would have to do some instanceof checking on itself to get this working) and that a validator can be a behavior in the add(I(Form)Validator) method. Yuk. If they "really" share a common interface, their should not be two separate "add" APIs. overloading the add method for two very different purposes is a very bad idea IMO. I think this should be changed regardless of this new feature. A way to fix this is to create a common interface (in my implementation I called this IComponentFacet) for IBehavior and IValidator and have one add method. In the mechanism I implemented, facets were stored in the same structure (so the validators field in FormComponent was removed) and it worked with a lookup method like getFacets(Class). I agree with Al that seeing an IDE autocomplete a "Facet" instead of "Behavior" or "Validator" is a really big deal. I don't think it's worth it right now. I guess my point is made. I'll back off for a bit and see what other people have to say about this. Anyone's opinions are welcome, and core developers, please contribute so that we can make this decision in consensus. KISS. Keep It Simple (Stupid) :) The current solution is simple, but I thought there were objections because the Validator API is fairly independent of the internal wicket? I know you have to use this new optional interface, but it makes perfect sense for some of the core wicket validators to start using this feature ASAP. The max-length validator is a perfect example where this feature is needed. Start small, and don't try to support every usecase. IMO, getting the ball rolling with the max-length validation is a great start. Ryan
inspecting property models
This discussion came out of the recent hibernate wicket-stuff activity. For my behaviors/validators/listeners to work, I need to have visibility into the PropertyModel's internal configuration. In particular, I need access to the: * propertyExpression configured for a particular form component * targetClass that this model is using I've worked around this for now by creating a subclass (HibernateAnnotationPropertyModel), but it's pretty restrictive and unfortunate that users are forced to use this non-standard property model. Any opinions on a better way to go about this, or change the wicket-core to support this use case? http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/
Re: Hibernate Validator integration?
On 5/10/07, Johan Compagner <[EMAIL PROTECTED]> wrote: and i don't like that that is mixing 2 classes as once thing that means no reuse what so ever. This just makes big copy paste actions. it should be possible to seperate IValidator and IBehavior implementations else if i want to use an IValidator i have to reimplement it yes ofcourse i can make my behavior implement also IValidator and then passthrough everything of the IValidtor to the real validator that is again a delegate. we just don't have multiply inheritance in java.. Thank God we don't have multiple inheritance... Since these interfaces are so thin, creating a class that implements both interfaces and delgates to separate implementation classes should be pretty light weight.
Re: Hibernate Validator integration?
On 5/10/07, Al Maw <[EMAIL PROTECTED]> wrote: Ryan Sonnek wrote: > I'd appreciate anyone interested to take a look and let me know what > they think. You currently setRequired(true) on a NotEmpty, which isn't what that intends at all. It's purpose is to make sure a String is length > 0, or a collection has more than zero elements. Might not be correct for collections, but should work for strings right? Similarly, the Length element can and probably should be using a StringValidator for a TextField and not setting maxlength. Maybe it should do both. ;-) I've thought about using validators here and "ideally" would use a StringValidatorWithBehavior that would automatically attach the markup attributes. any thoughts? It strikes me we probably need a: Hibernate Validator Attribute + Component type -> Validator mapping ...because what sort of validator you want to use will be dependent on the component type. Al I actually think I would like to create a application component listener for this (similar to the SpringBean component listener) so that an entire application will "just work" and you don't have to worry about manually adding validators at all. thoughts? Ryan
Re: Hibernate Validator integration?
I'm a little confused on how these changes would impact the hibernate
integration. anyone care to spell out how this changes the code?
On 5/9/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Sounds good to me.
Eelco
On 5/9/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> what about making iformvalidator extend ivalidator. and ibehaviorprovider
> extend ivalidator.
>
> in formvalidator validatable.value can be form.modelobject() and
> validatable.error reports an error on form.
>
> -igor
>
>
> On 5/9/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> >
> > > no. dont forget that the idea of IValidator is to be decoupled from
> > wicket,
> > > to allow the reuse of validators in service layer. i do that all the
> > time
> > > now and it rocks! my service layer and my ui layer are validated by the
> > same
> > > code. adding ivalidator.getbehavior() will break all that nice
> > decoupling.
> > >
> > > i always thought that something like this would work
> > >
> > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > validate
> > > the value */ CharSequence getValidationScript(); }
> >
> > /**
> > * Validator that provides a behavior, e.g. for rendering client-side or
> > ajax
> > * validation. This interface can be implemented by either
> > * [EMAIL PROTECTED] IValidator validators} or [EMAIL PROTECTED]
IFormValidator form validators}.
> > */
> > public interface IBehaviorProvider extends IClusterable
> > {
> > /**
> > * Gets behavior for validation.
> > *
> > * @param component
> > *component currently using the validator
> > * @return The behavior, which can be used for rendering e.g.
> > */
> > IBehavior getValidationBehavior(Component component);
> > }
> >
> > same here, instanceof check and ready. Not extra code as how to
> > interpret it, and all the flexibility that behaviors provide.
> >
> > Eelco
> >
>
Re: Hibernate Validator integration?
AJAX vs client side validation is a really good point. I'll keep this in mind and try to leverage server side logic as much as possible. On 5/9/07, Johan Compagner <[EMAIL PROTECTED]> wrote: also when you look at client side validation look into ajax validation currently i don't find client side that big of an issue. because you can use your java validation rules just fine when you use ajax.. johan On 5/9/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > Wow. After a flurry of research into this area, i've whipped together > a hibernate/wicket behavior that reads annotations and helps configure > the wicket component respectively. > > http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/ > > Essentially, right now it will auto configure a component by: > * set component to be "required" when using NotNull annotation > * add "maxlength" attribute when using Length annotation > > Still lots of work to be done: > * attach client side javascript validation > * maybe integrate into the wicket validation framework? > > I'd appreciate anyone interested to take a look and let me know what they > think. > > On 5/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > Ryan, lets finish this thread and move on to gTalk and *talk* about > this. > > > I'm adding you right now. > > > > Or even better... why don't you guys join the ##wicket IRC channel on > > freenode.net? It's perfect for discussions like that, and changes are > > you'll get some more people opinions in the process (44 people hanging > > out as I write this). > > > > > No, I dont have an account yet, and yes you can start the project in > > > wicket-stuff and after that, I'll ask you for permission. What'd you > think? > > > > Please reply with (or send me) your sourceforge id, and I'll be happy > > to add you to wicket-stuff. > > > > Eelco > > >
Re: making
Yeah, I'm talking about the code for the wicket-hibernate-behavior project. http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/ I was writing it against 1.2.x, but just upgraded it to 1.3 last night. Again, I'm open to "another way" to do this if it's preferred to not change these methods. On 5/9/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Are you talking about 1.2 code Ryan? I wouldn't have a problem exposing such. But before we do, I think we should decide on an interface that exposes that and that can be used by more models. A related thing is something we had a little brain storm about after a comment in Matej's ApacheCon session, which is to have a way to expose the target type of a model (optinionally, if the model can/ wants) so that e.g. we can get rid of that ugly type argument in text components. That should probably result in an interface, e.g. IModelTypeAware or such. Eelco On 5/9/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > but what do you really need inside that client side validation? > what do you want to do with the propertyExpression? > > johan > > > On 5/9/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > > can these methods be made public? > > AbstractPropertyModel#propertyExpression > > AbstractPropertyModel#propertyType > > > > I'm open to suggestions, but what I'm trying to do is build a behavior > > that inspects the model to attach client side validation. I'm trying > > to extract the PropertyModel expression to lookup annotations for that > > field. If there's a better way to do this, I'm open to ideas! > > > > Thanks, > > Ryan > > >
Re: Hibernate Validator integration?
I also think that the solution is a bit hackish. It's great to make things work quickly, but in this case I'd rather see whether we can find something generic, even if that would mean alterations in Wicket's (internal) API as well. A *bit* hackish? =) I'd say a *lot* hackish right now. I just wanted to get this out the door because A. It "works" B. to try and get some direction on where this kind of project should go. Thanks for the initial feedback, and I hope to hear more about where to take this.
Re: Hibernate Validator integration?
Wow. After a flurry of research into this area, i've whipped together a hibernate/wicket behavior that reads annotations and helps configure the wicket component respectively. http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/ Essentially, right now it will auto configure a component by: * set component to be "required" when using NotNull annotation * add "maxlength" attribute when using Length annotation Still lots of work to be done: * attach client side javascript validation * maybe integrate into the wicket validation framework? I'd appreciate anyone interested to take a look and let me know what they think. On 5/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Ryan, lets finish this thread and move on to gTalk and *talk* about this. > I'm adding you right now. Or even better... why don't you guys join the ##wicket IRC channel on freenode.net? It's perfect for discussions like that, and changes are you'll get some more people opinions in the process (44 people hanging out as I write this). > No, I dont have an account yet, and yes you can start the project in > wicket-stuff and after that, I'll ask you for permission. What'd you think? Please reply with (or send me) your sourceforge id, and I'll be happy to add you to wicket-stuff. Eelco
making
can these methods be made public? AbstractPropertyModel#propertyExpression AbstractPropertyModel#propertyType I'm open to suggestions, but what I'm trying to do is build a behavior that inspects the model to attach client side validation. I'm trying to extract the PropertyModel expression to lookup annotations for that field. If there's a better way to do this, I'm open to ideas! Thanks, Ryan
Re: Hibernate Validator integration?
Hey Bruno, I'd love to contribute. My experience with annotations and hibernate validators is very limited, but I'd love to dig in. do you have any place to start for source code? I'd like to start a small project in wicket-stuff to try this out. do you have account setup for wicket-stuff access? On 5/8/07, Bruno Borges <[EMAIL PROTECTED]> wrote: Ryan, want to work together on this? Regards, -- Bruno Borges Summa Technologies Inc. www.summa-tech.com (48) 8404-1300 (11) 3055-2060 On 5/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > I think someone (you?) just has to take up the initiative. I think the > core team is too tight up atm. > > Eelco > > > On 5/8/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > I haven't heard anything on this thread for a while, and it seemed > > really exciting. Has there been any progress on creating a wicket > > validator that uses hibernate annotations? anything available in > > wicket-stuff to take a look at? > > > > On 4/25/07, Xavier Hanin <[EMAIL PROTECTED]> wrote: > > > On 4/25/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > naah, we share this list with wicket-stuff. makes it easier. > > > Ok, sorry, next time I'll just put a +1 to give my opinion, it will > > > save a couple of emails :-) > > > > > > Xavier > > > > > > > > > > > -igor > > > > > > > > > > > > On 4/25/07, Xavier Hanin <[EMAIL PROTECTED]> wrote: > > > > > > > > > > On 4/25/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > > > why would our opinion matter? you are free to start a > wicket-stuff > > > > > project > > > > > > to integrate whatever you want :) > > > > > Agreed, but since Bruno posted on the dev mailing list, I thought > he > > > > > was more specifically asking opinion from the wicket team. > > > > > > > > > > Xavier > > > > > > > > > > > > > > > > > -igor > > > > > > > > > > > > > > > > > > On 4/25/07, Xavier Hanin <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > On 4/25/07, Bruno Borges <[EMAIL PROTECTED]> wrote: > > > > > > > > Sorry.. worst than Draft Review: JSR 303 is in Draft Ballot > yet!! So > > > > > > > it'll > > > > > > > > take some time until a final specification for this under > JPA. :( > > > > > > > > > > > > > > > > Let's continue with HV ? :D > > > > > > > It seems reasonable to me, but the opinion from Wicket team > would be > > > > > > > much more valuable than mine. > > > > > > > > > > > > > > Xavier > > > > > > > > > > > > > > > > []'s > > > > > > > > -- > > > > > > > > Bruno Borges > > > > > > > > Summa Technologies Inc. > > > > > > > > www.summa-tech.com > > > > > > > > (48) 8404-1300 > > > > > > > > (11) 3055-2060 > > > > > > > > > > > > > > > > On 4/25/07, Bruno Borges <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > Hibernate Validation is related to JSR 303< > > > > > > > http://jcp.org/en/jsr/detail?id=303>, > > > > > > > > > which is in draft review yet... :( > > > > > > > > > And most probably HV will be used as RI with changes to > JPA for > > > > > sure. > > > > > > > > > But maybe it can start as a contrib project, what'd you > think? > > > > > > > > > > > > > > > > > > []'s > > > > > > > > > -- > > > > > > > > > Bruno Borges > > > > > > > > > Summa Technologies Inc. > > > > > > > > > www.summa-tech.com > > > > > > > > > (48) 8404-1300 > > > > > > > > > (11) 3055-2060 > > > > > > > > > > > > > > > > > > On 4/25/07, Xavier Hanin <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > &g
Re: Hibernate Validator integration?
I haven't heard anything on this thread for a while, and it seemed
really exciting. Has there been any progress on creating a wicket
validator that uses hibernate annotations? anything available in
wicket-stuff to take a look at?
On 4/25/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
On 4/25/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> naah, we share this list with wicket-stuff. makes it easier.
Ok, sorry, next time I'll just put a +1 to give my opinion, it will
save a couple of emails :-)
Xavier
>
> -igor
>
>
> On 4/25/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> >
> > On 4/25/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > why would our opinion matter? you are free to start a wicket-stuff
> > project
> > > to integrate whatever you want :)
> > Agreed, but since Bruno posted on the dev mailing list, I thought he
> > was more specifically asking opinion from the wicket team.
> >
> > Xavier
> >
> > >
> > > -igor
> > >
> > >
> > > On 4/25/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On 4/25/07, Bruno Borges <[EMAIL PROTECTED]> wrote:
> > > > > Sorry.. worst than Draft Review: JSR 303 is in Draft Ballot yet!! So
> > > > it'll
> > > > > take some time until a final specification for this under JPA. :(
> > > > >
> > > > > Let's continue with HV ? :D
> > > > It seems reasonable to me, but the opinion from Wicket team would be
> > > > much more valuable than mine.
> > > >
> > > > Xavier
> > > > >
> > > > > []'s
> > > > > --
> > > > > Bruno Borges
> > > > > Summa Technologies Inc.
> > > > > www.summa-tech.com
> > > > > (48) 8404-1300
> > > > > (11) 3055-2060
> > > > >
> > > > > On 4/25/07, Bruno Borges <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Hibernate Validation is related to JSR 303<
> > > > http://jcp.org/en/jsr/detail?id=303>,
> > > > > > which is in draft review yet... :(
> > > > > > And most probably HV will be used as RI with changes to JPA for
> > sure.
> > > > > > But maybe it can start as a contrib project, what'd you think?
> > > > > >
> > > > > > []'s
> > > > > > --
> > > > > > Bruno Borges
> > > > > > Summa Technologies Inc.
> > > > > > www.summa-tech.com
> > > > > > (48) 8404-1300
> > > > > > (11) 3055-2060
> > > > > >
> > > > > > On 4/25/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > I haven't had time to check HV in depth for the moment but I've
> > > > heard
> > > > > > > good things about it, and was about to ask the same question as
> > > > Bruno,
> > > > > > > because I would be interested too in such a validator.
> > > > > > >
> > > > > > > Martijn, doesn't your proposition to rely on JPA spec instead of
> > HV
> > > > > > > imply to rewrite sg similar to what has been done in HV?
> > > > > > >
> > > > > > > Xavier
> > > > > > >
> > > > > > > On 4/25/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> > > > > > > > I would most like want this to be built against the JPA spec
> > > > instead
> > > > > > > > of directly implementing Hibernate's validators. Then we can
> > use
> > > > it
> > > > > > > > for toplink, hibernate, openjpa, etc. And it is Apache license
> > > > > > > > friendly too.
> > > > > > > >
> > > > > > > > Martijn
> > > > > > > >
> > > > > > > > On 4/25/07, Bruno Borges < [EMAIL PROTECTED]> wrote:
> > > > > > > > > I was thinking of a Validator like the Ajax one. See this
> > > > example:
> > > > > > > > >
> > > > > > > > > TextField email = new TextField("email");
> > > > > > > > > email.add(new JPAValidator()); // or new JPAValidator(
> > Pojo.class
> > > > );
> > > > > > > > >
> > > > > > > > > And the class scans the Model for annotated properties and
> > adds
> > > > the
> > > > > > > related
> > > > > > > > > Wicket validators automatically. If the Model is a POJO not
> > > > > > > annotated with
> > > > > > > > > @Entity, its possible to use JPAValidator(Class clazz);.
> > > > > > > > >
> > > > > > > > > @EmailValidation // a custom HV email's annotation pattern
> > > > > > > > > public String getEmail() { return email; }
> > > > > > > > >
> > > > > > > > > What you guys think about this? (I like to see the code I'd
> > like
> > > > to
> > > > > > > use and
> > > > > > > > > implement it around the examples... :D )
> > > > > > > > >
> > > > > > > > > []'s
> > > > > > > > > --
> > > > > > > > > Bruno Borges
> > > > > > > > > Summa Technologies Inc.
> > > > > > > > > www.summa-tech.com
> > > > > > > > > (48) 8404-1300
> > > > > > > > > (11) 3055-2060
> > > > > > > > >
> > > > > > > > > On 4/24/07, Eelco Hillenius < [EMAIL PROTECTED]>
> > wrote:
> > > > > > > > > >
> > > > > > > > > > I've been thinking about it, haven't got around doing it.
> > > > Should
> > > > > > > be
> > > > > > > > > > pretty easy to do, especially with our shiny new
> > validators.
> > > > Maybe
> > > > > > > we
> > > > > > > > > > can make this a shared effort?
> > > > > > > > > >
> > > > > > > > > > Eelco
> > > > > > > > > >
> > > > > > > > > > On 4/24/07, Bruno Borges <[EMAIL PROTECTED] > wrote:
> > > > > > > > > > > Has anybody made an
Re: wicket-velocity : making VelocityPanel abstract
i'm no committer, but i'm -1 for this change. just my 2 cents. i'd much rather use constructor arguments to ensure correct construction than overriding methods. On 5/7/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: Hi team, Thanks for adding wicket-velocity. One suggestion though, can we make VelocityPanel abstract to let the user return the IStringResourceStream instead of passing it in the constructor? That would be nicer. That would also allow to simplify the example, currently building the template inline with StringBuffer. This is an incompatible change, but nobody depends on it already, right? WDYT? See patch attached. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)
i think what we should do is create a two-tier system where projects that are alive are directly in trunk, while other projects are in a subdirectory of trunk. projects can move between these two tiers as needed. Perhaps a wicket-stuff-incubator?? ideas can be tried out in the incubator module and promoted to a top level if it becomes a "real" project. Now, the definition of what constitutes a "real" project is still up to debate. =)
Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3
As a wicket-stuff developer, I for one would hate to see restrictions placed on what can or can not be a wicket-stuff project. The beauty of the wicket-stuff idea is that it is a playground for people try out potentially cool ideas. It's a place for people to learn how to use wicket and build "possibly" cool widgets and tools. I know that *my* project (wicketstuff-scriptaculous) has occasionally been left "in the dark" for several months before a whole slew of changes and features get built in. Sure, there may be a "better" wicket/hibernate project out there (aka: databinder), but I really don't see any issues with that. Especially now that there's a wicket-stuff wiki, it can be clearly spelled out there what each project's strengths/weaknesses are. On 5/6/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Well, then someone would complain wouldn't they? You know what, I'm sick of this and deleted the projects, including the wicket-stuff-examples, which was another one of these projects only maintained by me. As you brought this up Martijn, please do a review of the other wicket-stuff projects that are *possibly* not actively 'maintained' (wicket-database, datepicker, gmap?). Let's do the cleanup properly then. Eelco On 5/6/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > well, yes it does matter. there is a difference between a project and a > bunch of compiling code. for example that project will break if anyone tries > to use it with hibernate 3.2 because it hasnt been updated to their switch > of aggregate return types form int to long. who knows what else is broken. > this project needs to be maintained from both ends: wicket and hibernate. > and you are only doing it form one end. > > -igor > > > On 5/6/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > you _maintain_ them as far as keeping api with wicket in sync. but do > > you > > > actively develop them? do they provide any value in their current state? > > are > > > they up to the latest hibernate version? > > > > Huh? Does it matter for this project more than other wicket-stuff > > projects? Does it matter what release of Hibernate it's on? Don't you > > have more important things to do than to bith about wicket-stuff > > projects that I say I take responsibility for? > > > > > imho those projects never got finished, not even close. > > > > The great motivator speaks again. > > > > Eelco > > >
What is ScriptaculousRequestTarget?
http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicket-contrib-scriptaculous/src/java/org/wicketstuff/scriptaculous/ScriptaculousRequestTarget.java?revision=2024&view=markup I have been backporting features from the 2.0 branch to the new trunk and came across this very odd class. Why was this added? It looks to be locking on the session to stream output back to the user. seems like this would prevent multiple "asynchronous" ajax requests? also, this really doesn't seem relevant to the scriptaculous project... any ideas on who/why this was added?
Re: Hibernate Validator integration?
+1 for just "getting something working". use wicket-stuff for now and
worry about licensing *if* it works well enough to try and push into
the core.
On 4/25/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
why would our opinion matter? you are free to start a wicket-stuff project
to integrate whatever you want :)
-igor
On 4/25/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
>
> On 4/25/07, Bruno Borges <[EMAIL PROTECTED]> wrote:
> > Sorry.. worst than Draft Review: JSR 303 is in Draft Ballot yet!! So
> it'll
> > take some time until a final specification for this under JPA. :(
> >
> > Let's continue with HV ? :D
> It seems reasonable to me, but the opinion from Wicket team would be
> much more valuable than mine.
>
> Xavier
> >
> > []'s
> > --
> > Bruno Borges
> > Summa Technologies Inc.
> > www.summa-tech.com
> > (48) 8404-1300
> > (11) 3055-2060
> >
> > On 4/25/07, Bruno Borges <[EMAIL PROTECTED]> wrote:
> > >
> > > Hibernate Validation is related to JSR 303<
> http://jcp.org/en/jsr/detail?id=303>,
> > > which is in draft review yet... :(
> > > And most probably HV will be used as RI with changes to JPA for sure.
> > > But maybe it can start as a contrib project, what'd you think?
> > >
> > > []'s
> > > --
> > > Bruno Borges
> > > Summa Technologies Inc.
> > > www.summa-tech.com
> > > (48) 8404-1300
> > > (11) 3055-2060
> > >
> > > On 4/25/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I haven't had time to check HV in depth for the moment but I've
> heard
> > > > good things about it, and was about to ask the same question as
> Bruno,
> > > > because I would be interested too in such a validator.
> > > >
> > > > Martijn, doesn't your proposition to rely on JPA spec instead of HV
> > > > imply to rewrite sg similar to what has been done in HV?
> > > >
> > > > Xavier
> > > >
> > > > On 4/25/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> > > > > I would most like want this to be built against the JPA spec
> instead
> > > > > of directly implementing Hibernate's validators. Then we can use
> it
> > > > > for toplink, hibernate, openjpa, etc. And it is Apache license
> > > > > friendly too.
> > > > >
> > > > > Martijn
> > > > >
> > > > > On 4/25/07, Bruno Borges < [EMAIL PROTECTED]> wrote:
> > > > > > I was thinking of a Validator like the Ajax one. See this
> example:
> > > > > >
> > > > > > TextField email = new TextField("email");
> > > > > > email.add(new JPAValidator()); // or new JPAValidator(Pojo.class
> );
> > > > > >
> > > > > > And the class scans the Model for annotated properties and adds
> the
> > > > related
> > > > > > Wicket validators automatically. If the Model is a POJO not
> > > > annotated with
> > > > > > @Entity, its possible to use JPAValidator(Class clazz);.
> > > > > >
> > > > > > @EmailValidation // a custom HV email's annotation pattern
> > > > > > public String getEmail() { return email; }
> > > > > >
> > > > > > What you guys think about this? (I like to see the code I'd like
> to
> > > > use and
> > > > > > implement it around the examples... :D )
> > > > > >
> > > > > > []'s
> > > > > > --
> > > > > > Bruno Borges
> > > > > > Summa Technologies Inc.
> > > > > > www.summa-tech.com
> > > > > > (48) 8404-1300
> > > > > > (11) 3055-2060
> > > > > >
> > > > > > On 4/24/07, Eelco Hillenius < [EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > I've been thinking about it, haven't got around doing it.
> Should
> > > > be
> > > > > > > pretty easy to do, especially with our shiny new validators.
> Maybe
> > > > we
> > > > > > > can make this a shared effort?
> > > > > > >
> > > > > > > Eelco
> > > > > > >
> > > > > > > On 4/24/07, Bruno Borges <[EMAIL PROTECTED] > wrote:
> > > > > > > > Has anybody made an integration between Wicket and Hibernate
> > > > Validator?
> > > > > > > HV
> > > > > > > > is probably going to be the reference implementation for JSR
> 303
> > > > and
> > > > > > > JBoss
> > > > > > > > Seams use it integrated with JSF. Looks cool...
> > > > > > > >
> > > > > > > > http://hibernate.org/412.html
> > > > > > > > http://jcp.org/en/jsr/detail?id=303
> > > > > > > >
> > > > > > > > Cheers
> > > > > > > > --
> > > > > > > > Bruno Borges
> > > > > > > > Summa Technologies Inc.
> > > > > > > > www.summa-tech.com
> > > > > > > > (48) 8404-1300
> > > > > > > > (11) 3055-2060
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Learn Wicket at ApacheCon Europe: http://apachecon.com
> > > > > Join the wicket community at irc.freenode.net: ##wicket
> > > > > Wicket 1.2.6 contains a very important fix. Download Wicket now!
> > > > > http://wicketframework.org
> > > > >
> > > >
> > > >
> > > > --
> > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > Manage your dependencies with Ivy!
> > > > http://incubator.apache.org/ivy/
> > > >
> > >
> > >
> >
>
>
> --
> Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> Manage your dependencies with Ivy!
> http://incubator.apache.org/ivy/
>
Re: Animation libs compared: animate.js versus Yahoo! Animation
Nice work! On my PC (linux, firefox 1.5), the animation.js version is *much* snappier. On 4/15/07, Matej Knopp <[EMAIL PROTECTED]> wrote: Firefox 2.0, OSX, both animations perform roughly the same, yahoo being little bit smoother. But the size difference makes animator better pick i think. Also this is not the general use-case for animations imho :) -Matej On 4/15/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > All, > > I've been working for a while now on an animated homepage for wicket > (not that we *have* to use it, it is a gimmick), and it was originally > based on animate.js (the proposed animation library). I also converted > it to yahoo animation (which is quite similar), and this way we can > see the differences between the two (peformance, API, etc). > > You can see the difference between the two libs here: > > http://people.apache.org/~dashorst/animation/animator.html > http://people.apache.org/~dashorst/animation/yahoo.html > > If you want to see the difference between rendering engines: I found > that firefox has the best javascript support for these animations. > Safari runs at a snails pace (I had to tweak the animation for that to > make it run faster). > > Lessons learned: > - animate.js is a really nice and powerful library > - yahoo animation gives similar results, and has a bit better > animation management > - safari sucks performance wise for javascript > - the api for yahoo and animate is strikingly similar, with just a > couple of differences > > I haven't tested this with IE so that may be completely broken. > > Martijn > > -- > Learn Wicket at ApacheCon Europe: http://apachecon.com > Join the wicket community at irc.freenode.net: ##wicket > Wicket 1.2.5 will keep your server alive. Download Wicket now! > http://wicketframework.org >
Re: Package rename at SourceForge
along with the package renaming, i think it's important for the project artifact to be updated as well. groupID = org.wicketstuff artifactID = dojo ??? after some more thought, i think the artifactID should be something like wicket-dojo or wicketstuff-dojo. The artifactID is used to name the created jar file and having the wicketstuff jars just named "dojo" or "scriptaculous" seems a bit confusing.
Re: Package rename at SourceForge
On 4/10/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Al and I have been contemplating introducing a Wicket stuff parent pom that gives all projects the same stuff for group id, lists, svn. +1 for a common parent pom.
Re: Package rename at SourceForge
I like that idea and think it would make sense for the other "wicket-contrib-*" projects to do the same. along with the package renaming, i think it's important for the project artifact to be updated as well. groupID = org.wicketstuff artifactID = dojo ??? On 4/10/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: I'm thinking of renaming to org.wicketstuff.dojo instead. WDYT? -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: roadmap
But see, it is not relevant for the people who are on 2.0, as they are using those features *today*. They have code that compiles today and projects they are working on today. They are not working on 2.0 to end up with 1.4 or 1.5; the only time they would do that is when we decide to drop 2.0. You can imagine they don't want to rewrite the models and validators and generics only to put it in at *some* later time *if* we decide to put these features in. I'm a user of wicket 2.0, and I'm not worried about changes "breaking" my app. the only people using 2.0 for their apps are either building the source directly, or pulling down maven snapshots. either way, they've either gotten used to "bleeding" edge development, or they've moved to a more stable version (1.3). Before worrying so much about providing 2.0 users with a migration path, make sure that 2.0 users even *need* it. I really don't think there are that many people using 2.0. I'm not worried about these changes "breaking" my app and I'm sure anyone using 2.0 today is very plugged into the ever changing codebase.
Re: VOTE: add Joda time as a dependency
good idea. similar to the wicket-spring module. On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: -1 for core +0 for extensions +1 for a wicket-joda core module extensions is getting pretty big, its hard to find things. if i am using joda in my project and see wicket-joda i immediately know what it is and i can easily browse the contents and only see things that interest me. -igor On 2/3/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > And jar size doesn't really matter on the server, does it? I find that > argument pretty much a non-issue. > > I don't like the fact that we are going to depend on a library and > find out that in Java 7 it is no longer necessary (it is now a JSR). > The problem is that they are not rubberstamping Joda but again doing a > whole committee thing. This would mean new api's etc. At least with > concurrent.jar they just rubberstamped the lot and incorporated it in > java 5. > > Even though java.util.Date and java.util.Calendar are not perfect, > they are the most used date implementations available and for instance > Hibernate/JDBC/ibatis/etc. works directly with that. For such bindings > you have to resort to yet another library/dependency if I'm not > mistaken. > > I'm -0 for core, but +1 for extensions. It is not that we want to > change the world by making the whole Java experience better, just the > HTML serving part. Adding it to extensions and seeing the response to > that will give us time to mature it and see if we can build more on > top of it. > > Martijn > > On 2/3/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > why is it so big? complete wicket is 1.5 so only some date manipulations > are > > 1/3th? > > > > johan > > > > > > On 2/2/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > > Hi all, > > > > > > For those who don't know, Joda Time: http://joda-time.sourceforge.net/ > > > is a *much* better replacement of the Java date and time APIs it many > > > ways (see their 'why Joda time section'). Also, Joda time will be the > > > basis of JSR 310 (http://jcp.org/en/jsr/detail?id=310). > > > > > > Date/ time handling wouldn't normally be part of Wicket's > > > responsibility, wouldn't it be the fact that our date related > > > components suffer from the JDKs API being bad. I wrote some components > > > and a converter based on Joda time that work better than the current > > > ones we have. The most important feature of those components is that > > > they take the client's time zone into account. I've tried to write > > > them against the normal date/time API, but got so sick of battling it > > > that I gave up. And as soon as I adopted Joda time (which we were > > > already using for our project), it worked superb! > > > > > > My proposal is to include Joda time as a dependency of the wicket core > > > project. I know *any* extra dependency raises eyebrows and I feel > > > great about Wicket hardly having any dependencies at the moment. > > > However, I feel this library is so good and could improve our core > > > components and converters so much that it is worth having the extra > > > dependency. > > > > > > Joda time is a maven 2 project, is Apache 2.0 licensed, and version > > > 1.4 is 512KB. > > > > > > Your thoughts/ votes? > > > > > > Eelco > > > > > > > > -- > Vote for Wicket at the > http://www.thebeststuffintheworld.com/vote_for/wicket > Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now! > http://wicketframework.org >
Re: VOTE: add Joda time as a dependency
I'm all for using something that actually works. =) On 2/2/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > even if it is better than the core wicket binder It's not just better, the current date converter is just wrong/ naive imo (though this is a problem with most if not all competitors as well in suspect). Eelco
Re: VOTE: add Joda time as a dependency
-1 I'm a big fan of joda time, but i think this should really be an "extension". even if it is better than the core wicket binder, 1/2MB is a large addition to any project. On 2/2/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: exactly what will you improve in core by having joda time? why cant it be a dependency on the extensions? or why not make it a core module all onto itself? -igor On 2/2/07, Philip A. Chapman <[EMAIL PROTECTED]> wrote: > > My non-binding vote is go for it. > > Eelco Hillenius wrote: > > Hi all, > > > > For those who don't know, Joda Time: http://joda-time.sourceforge.net/ > > is a *much* better replacement of the Java date and time APIs it many > > ways (see their 'why Joda time section'). Also, Joda time will be the > > basis of JSR 310 (http://jcp.org/en/jsr/detail?id=310). > > > > Date/ time handling wouldn't normally be part of Wicket's > > responsibility, wouldn't it be the fact that our date related > > components suffer from the JDKs API being bad. I wrote some components > > and a converter based on Joda time that work better than the current > > ones we have. The most important feature of those components is that > > they take the client's time zone into account. I've tried to write > > them against the normal date/time API, but got so sick of battling it > > that I gave up. And as soon as I adopted Joda time (which we were > > already using for our project), it worked superb! > > > > My proposal is to include Joda time as a dependency of the wicket core > > project. I know *any* extra dependency raises eyebrows and I feel > > great about Wicket hardly having any dependencies at the moment. > > However, I feel this library is so good and could improve our core > > components and converters so much that it is worth having the extra > > dependency. > > > > Joda time is a maven 2 project, is Apache 2.0 licensed, and version > > 1.4 is 512KB. > > > > Your thoughts/ votes? > > > > Eelco > > > > > >
Re: Packaging our releases
+1 to Igor's response Use maven conventions as much as possible. Leave the distributions "bare bones" and get all extra artifacts (source, javadoc) in the maven repository. On 1/22/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Other peops than core devs please voice your opinion. The distributions are made for you. Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now! http://wicketframework.org
Re: http://issues.apache.org/jira/browse/WICKET-151
Right. It would be imposible to have MyPage_en.html or MyPage_en.properties if wicket didn't know about the locale. On 1/5/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: of course wicket needs it - it needs to know which markup and properties file to use. -igor On 1/5/07, Korbinian Bachl <[EMAIL PROTECTED]> wrote: > > in my opinion, i even dont understand why the core sets a locale, wicket > itself dont need it - everything that is needed should be specified by the > application programmer - if he needs a locale he will put one into a > extended class as nice as he wants it (and with J5EE its relly nice as you > can have a Static CustomClass getCustomClass returning your CustomClass) > and > if he neednt a locale he will not take care about it... > > just my 2 cents > > > -Ursprüngliche Nachricht- > > Von: Eelco Hillenius [mailto:[EMAIL PROTECTED] > > Gesendet: Freitag, 5. Januar 2007 06:45 > > An: wicket-dev@incubator.apache.org > > Betreff: http://issues.apache.org/jira/browse/WICKET-151 > > > > any others have an opinion about > > http://issues.apache.org/jira/browse/WICKET-151 ? > > > > Eelco > > > >
Re: wicket 2.0 migrated to slf4j
can't this be added to the wicket POM so that all wicket 2.0 projects automatically pick it up? On 12/29/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote: I added it to the Wicket 2.0 Migration Page on the Wiki, hope this is ok. Regards > -Ursprüngliche Nachricht- > Von: Igor Vaynberg [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 29. Dezember 2006 08:56 > An: wicket-dev@incubator.apache.org; wicket-user@lists.sourceforge.net > Betreff: wicket 2.0 migrated to slf4j > > i have just migrated wicket 2.0 from commons-logging to slf4j > as was previously discussed and agreed upon. > > people using 2.0 need to add the following to their project's pom or > equivalent: > > if you are using commons-logging: > > > org.slf4j > slf4j-jcl > 1.1.0 > > > > if you are using log4j > > > org.slf4j > slf4j-log4j12 > 1.1.0 > > > these jars will bind slf4j to the proper logging library > > if you are using another logging impl like jdk see slf4j > website for the appropriate binding jar > > -igor >
Re: Why rewriting js librairies
Just so you know, There is a wicket-stuff project that integrates scriptaculous with Wicket. There'll be quite a few additions to that project comming soon too! On 11/10/06, Vincent demay <[EMAIL PROTECTED]> wrote: Hi, I ask myself a question. Why wicket needs to rewrite js libraries for ajax or other client-side scripts or to include external scripts (date picker for exemple). There are a lot of frameworks which work fine and do everything needed in wicket such as Dojo, script.aculo.us, etc...Why doesn't Wicket use one of them. -- Vincent Demay Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)561 000 649 Fax : +33 (0)561 005 146 http://www.anyware-tech.com/
Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
My vote is to not allow for inner forms either. It's too much framework "magic". Wicket is a web framework, and html doesn't allow for nested forms, so this seems totally counter-intuitive. On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: but how does this happen? why is the panel that has the search box and the button put _inside_ another form? let me give you the opposite example: right now i create a lot of editor objects that are panels with formcomponents. it would be great if i could have the panel also have a form so i can use an editor by itself and not need an external form. which usecase is more common? -igor On 11/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > I already did that in that other thread. > > One outer form where you can edit some database data and submit it > and an inner form that is just a search box so field and button'. > Then if i submit the edit for the outer form i really don't want to > process > the inner form.. > That inner form could be for example to search a value for that outer > form. > > So i am: > [X] Yes, don't process those pesky little fields > > to me it just doesn't make sense if you do it the other way why have that > inner form > where is the usecase for that? That one i can't think of immediately > > johan > > > On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > i would like to see a real world usecase where you would have nested > forms > > but will not want to process the inner when the outer is submitted. > > > > -igor > > > > > > On 11/5/06, Matej Knopp <[EMAIL PROTECTED]> wrote: > > > > > > People, people! > > > > > > I just don't get it. By no means I want to generate invalid input. > When > > > using nested forms only the toplevel form is generated as . All > > > nested forms are just s in html. > > > > > > The only difference is how the form is processed. If a nested form is > > > submitted, user input in all fields in entire form is persisted, only > > > the submitted form gets really processed. This is IMHO a great feature > > > and allows us to create components that are totally independent, e.g . > > > they don't have to care whether they are put in form or not, they can > > > contain their own form and everything will work as expected. > > > > > > All those remarks about getting against standard are just... well... > > > uninformed. We don't render anything against standard compliance. We > > > don't render things like > > > > > > > > > ... > > > > > > ... > > > > > > -Matej > > > > > > > > > > > > Nick Heudecker wrote: > > > > I'm -1 on allowing nested forms, and +1 on throwing a runtime error > if > > > this > > > > condition is encountered. Non-binding. > > > > > > > > On 11/5/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote: > > > >> > > > >> shame on me ... > > > >> > > > >> now serious > > > >> > I think the way we treat nested forms in 2.0 and 1.3 a real > > > >> > improvement and a showcase for component frameworks: work > > > >> > around problems in an elegant and meaningful way. Abstract > > > >> > away the limitations of the protocols we have to work with. > > > >> > > > >> i think this is a big danger - remember: most wicket users come > from > > a > > > >> point > > > >> of GUI building, they dont know the limitations of http, html, css, > > > >> ajax - > > > >> this ends usually up in trouble (security, locked out browsers, > > > >> unusability, > > > >> load, not barrer free...) > > > >> > > > >> my personal way is to always stick to standards - it might be > harder > > > >> sometimes to achive this, but youre on a save side... > > > >> > > > >> Regards > > > >> > > > >> Korbinian > > > >> > > > >> > -Ursprüngliche Nachricht- > > > >> > Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] > > > >> > Gesendet: Sonntag, 5. November 2006 22:00 > > > >> > An: wicket-dev@incubator.apache.org > > > >> > Betreff: Re: Re: [VOTE] Nested forms - don't process inner > > > >> > form fields in outer form submit > > > >> > > > > >> > On 11/5/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > >> > > > The vote: don't process inner form fields when the outer form > > is > > > >> > > > submitted [ ] Yes, don't process those pesky little > > > >> > fields [ ] No, > > > >> > > > process them as if they were part of the outer form > > > >> > > > > > >> > > I'm still not crazy about the whole concept, but I guess > > > >> > nested forms > > > >> > > can be useful sometimes. I just hope we don't open up > > > >> > another can of > > > >> > > worms. > > > >> > > > > >> > Hmmm breakfast. We already allow nested forms, but we > > > >> > don't do anything about it, and these fail horribly at the > > > >> > moment as Korbinian reminds us of constantly. The only other > > > >> > option would be to check the markup and throw a runtime > > > >> > exception that nesting is not allowed. > > > >> > > > > >> > I think the way we treat nested forms in 2.0 and 1.3 a real > > > >> > improvement and a showcase for compon
wicket bench javascript issues
if there's a seperate wicket-bench list I can take this issue there... I've had issues with wicket-bench-0.4.0 where my javascript (in ) was not being loaded on the first page load. It happened pretty regularly with firefox, and both firebug and the web-developer plugin were reporting issues. I was getting very concerned that this was a core wicket issue, until I started launching my application outside of wicket-bench using the jetty launcher. i haven't hit a single javascript load issue since. what's the issue? i think it's related to wicket-bench being loaded on the "/*" servlet mapping instead of "/app/*". if anyone can confirm or deny this, i'm open to suggestions. I'm also willing to help out the wicket-bench devs if they need any help with this. Ryan
Re: VOTE: double application settings
+1 for removing the code. duplicate code is confusing and defeats the purpose of "single responsibility per object". Single interface for single setting is a bit overboard, and i'm very pro "slim interfaces". =) On 10/16/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Yesterday I removed some double app settings, like isAjaxDebugModeEnabled() that was defined both in IAjaxSettings (removed) and in IDebugSettings. I did this because I was creating that JMX code, and thought someone made copy 'n paste bug/ forgot to remove a method after refactoring. Turns out, it was on purpose. This is a vote to find out whether people want this change reversed. I'm -1 because I think it's just crazy to have multiple interfaces with the same method sigs just for convenience. Imo it's bloat without real purpose, and it's even confusing. Imagine sitting behind that JMX interface and wondering which isAjaxDebugModeEnabled you should set. Also, I removed IAjaxSettings as isAjaxDebugModeEnabled() was the only method in it. I don't think we need to go back to just one settings interface, but we don't have to end up with too many of them either. For instance, having framework settings as a different interface is ok now that we have it, but wouldn't be my choice if we had to do it over again. Votes please? Eelco
Re: Wicket website design for Apache site
looks great, but I'd vote for no frames! On 10/11/06, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: Hi Martijn, Just one thing, the orange header is attracting too much the eyes, and there is not enough contrast between this header and the logo as they nearly have the same color. My 2¢, -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: optimizing markup ids
+1 for this.
i actually didn't know that it used the id attribute from the html if it was
defined. Learn something new every day...
On 10/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
ive been noticing more and more how rediculously long markup ids are
getting
in nontrivial pages. i mean a markupid of 50 characters? comon!
here is my take on optimizing the length and still keeping it reasonably
readeable. once we have support for figuring out if we are in prod or dev
mode we can optimize it even further by stripping component id.
should this go into 1.2? or wait for 1.3? or this idea sucks alltogether
and
should never see the light of svn?
-Igor
Index: D:/ws/wicket-1.x/src/java/wicket/Component.java
===
--- D:/ws/wicket-1.x/src/java/wicket/Component.java(revision 7558)
+++ D:/ws/wicket-1.x/src/java/wicket/Component.java(working copy)
@@ -915,26 +915,12 @@
*/
public String getMarkupId()
{
-/*
- * TODO Post 1.2: Restore the code below after the constructor
refactor,
- * right now its causing too much pain for components inside
listviews
- * and borders.
- *
- * CODE:
- *
- * String id = getMarkupAttributes().getString("id"); if (id ==
null) {
- * id = getPageRelativePath(); } return id;
- *
- * JAVADOC:
- *
- * If the id attribute is present in the markup attributes of
this
- * component it will be used, otherwise the page-relative path of
this
- * component will be used.
- *
- *
- */
-
-return getPageRelativePath().replace(':', '_');
+String markupId=(String)getMetaData(MARKUP_ID_KEY);
+if (markupId==null) {
+markupId=getId()+getPage().nextUniqueValue();
+setMetaData(MARKUP_ID_KEY, markupId);
+}
+return markupId;
}
/**
@@ -1665,6 +1651,13 @@
// Call any tag handler
onComponentTag(tag);
+Iterator handlers =
getApplicationSettings().getComponentTagHandlers().iterator();
+while (handlers.hasNext())
+{
+((IComponentTagHandler)handlers.next()).onComponentTag(this,
tag);
+}
+
+
// If we're an openclose tag
if (!tag.isOpenClose() && !tag.isOpen())
{
@@ -3066,4 +3059,15 @@
{
setFlag(FLAG_HEAD_RENDERED, false);
}
+
+
+/**
+ * Metadata key used to store/retrieve markup id
+ */
+private static MetaDataKey MARKUP_ID_KEY = new MetaDataKey(
String.class
)
+{
+
+private static final long serialVersionUID = 1L;
+
+};
}
I
Index: D:/ws/wicket-1.x/src/java/wicket/Page.java
===
--- D:/ws/wicket-1.x/src/java/wicket/Page.java(revision 7558)
+++ D:/ws/wicket-1.x/src/java/wicket/Page.java(working copy)
@@ -183,6 +183,10 @@
/** Version manager for this page */
private IPageVersionManager versionManager;
+
+/** Counter for generating unique values by calling # */
+private int counter;
+
/**
* Constructor.
*/
@@ -240,6 +244,15 @@
init(pageMap);
}
+
+/**
+ * @return unique integer value within the scope of the page
+ */
+public final int nextUniqueValue()
+{
+return counter++;
+}
+
javascript helper
I'm not sure how much of the core wicket framework programatically creates javascript, but I've been doing it a lot lately for the wicket-stuff scriptaculous project. I've written a helper class that has *drastically* cleaned up the Java code and made building javascript within Java pretty painless. If anyone is interested in using this in a seperate project, or the core, let me know. http://jroller.com/page/wireframe/?anchor=javascriptbuilder http://jroller.com/page/wireframe?entry=more_javascript_helpers
wicket bench
anyone know if the wicket-bench project is compatible with the wicket 2.0snapshots? I'm currently using wicket-bench version 0.4.0
Re: new AJAX EditInPlaceLabel
I had no idea one existed! any online demo available? It sure looks a lot more complex than what I've put together though. I'm using scriptaculous to do most of the heavy lifting for me. It also allows for a more "consistent" display with other websites that use scriptaculous and may not even be using Java. On 10/4/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: have you seen AjaxEditableLabel in extensions? :) -Igor On 10/4/06, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > I'm having issues with the mailing list, so I hope this makes it > through... > > I've just finished a first version of an Ajax Edit In Place Label. This > implementation uses scriptaculous and is similar to something found on > flickr. I've added it to the wicket-stuff project if anyone is interested > in taking a look. > > http://jroller.com/page/wireframe?entry=wicket_ajaxeditinplacelabel > >
new AJAX EditInPlaceLabel
I'm having issues with the mailing list, so I hope this makes it through... I've just finished a first version of an Ajax Edit In Place Label. This implementation uses scriptaculous and is similar to something found on flickr. I've added it to the wicket-stuff project if anyone is interested in taking a look. http://jroller.com/page/wireframe?entry=wicket_ajaxeditinplacelabel
