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
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
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
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
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
idmergere/id
nameMergere Maestro Repository/name
urlhttp://repo.mergere.com/maven2/url
/repository
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
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
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
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
??
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
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
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
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
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
(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
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
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
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
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,
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
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
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
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
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
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
http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicket-contrib-scriptaculous/src/java/org/wicketstuff/scriptaculous/ScriptaculousRequestTarget.java?revision=2024view=markup
I have been backporting features from the 2.0 branch to the new trunk
and came across this very odd
+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
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
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
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
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.
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.
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
-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
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
+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
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
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
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
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
wicket:head) was not being loaded on the first page load. It happened
pretty regularly with firefox, and both firebug and the web-developer plugin
were
40 matches
Mail list logo
