Hi Jeremy,
That sounds nice. I think this can be used to implement the wicket:for attribute
(to automatically set the 'for' attribute on 'label' tags) in a reasonably
elegant way. Though this might not be what you had in mind :)
Regards,
Erik.
Op 19-02-11 04:17, Jeremy Thomerson wrote:
Hi Attila,
Are you sure they are not used? They could be used transitively.
Anyways, in order for core to be consistent, having versions in the modules is
not desirable if they are already in the core pom.
Regards,
Erik.
Op 20-02-11 20:23, Attila Király wrote:
Hi!
I noticed that ther
I suppose it could, although I hadn't really thought about that part of it.
I'm not sure that would be a wise idea, but we're not blocking it that I
know of.
On Sun, Feb 20, 2011 at 10:45 PM, Clint Checketts wrote:
> So in theory a behavior implementing this could add additional
> components to
So in theory a behavior implementing this could add additional
components to the page? Or is the hierarchy frozen at this point?
On Friday, February 18, 2011, Jeremy Thomerson
wrote:
> What does everyone think about the following patch [1] to add two methods to
> IBehavior? Obviously, it's not
This vote is to release wicket 1.5-rc2
Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5-rc2/
Artifacts: http://people.apache.org/~ivaynberg/wicket-1.5-rc2/dist
Maven repo:
https://repository.apache.org/content/repositories/orgapachewicket-031/
Changelog:
https://issues.apache.o
This vote is to release wicket 1.4.16. This is a bugfix release on the
1.4.x (stable) branch.
Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.16/
Artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.16/dist
Maven repo:
https://repository.apache.org/content/repositories/org
Hi!
I noticed that there are a lot of dependencies in the dependencyManagement
section of wicketstuff-core/pom.xml that are actually not used by the
modules at all or the modules define the version for it (for
example: commons-dbutils, lucene, spring-hibernate3). Are these definitions
needed or co
> From an outside view the difference is whether the Enclosure is added
> automatically or manually. From an implementation point of view the
> automatic approach requires quite a bit of magic / complexity.
I hope you don't aim at almost watering the whole idea ;)
The idea of auto ajax enclosure
IMO it's quite a bit of (partially complex) code to achieve the objective.
Just a thought (I've not implemented/tested it). It'll not lead to the
very same result, but may be a less complex implementation =>
tradeoff. The basic idea: provided the child id is not necessarily
something the html desi
I did a first review.
- EnclosureHandler: A variable to increment the id postfix will not
work. A fresh copy of MarkupParser and all its handlers is created for
every markup file (page, panel, border, etc.). Your increment will
thus only be unique within the a single markup file. Your page however
10 matches
Mail list logo