Re: How to streamline ajax page region toggle
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
may have many Panels. That wouldn't be a problem for Wicket because of
its hierarchy, but HTML IDs must be unique on the page.
Markup parsing / loading is completely decoupled from wickets
components hierarchy, there is no Page available. That linkage happens
in Resolvers. See the EnclosureResolver for an example.
- besides that I think its poor practice to introduce a dependency on
Enclosure in MarkupContainer, auto-added components must be removed
after the render process as you otherwise keep on adding new ones and
your are not freeing them up. I don't understand anyway why you did
this change, since Enclosure don't have any state.
- you added code to EnclosureHandler and EnclosureResolver and
Enclosure. Tinkering a bit with the code, I think having an
InlineEnclosureHandler and InlineEnclosure keeps them nicely separated
and thus cleaner. InlineEnclosureHandler has only very little in
common with EnclosureHandler and could be separate, whereas
InlineEnclosure is probably better derived from Enclosure.
-Juergen
On Sun, Feb 20, 2011 at 5:51 AM, Joo Hama joonas.hamalai...@gmail.com wrote:
the problem with the tag is that it is not rendered into the markup so
cannot be targetted via ajax.
-igor
Yes, this is exactly the point. We cannot render Enclosure tags without
breaking html,
for example inside a table. If we cannot render it, we cannot target it
with ajax. When we
use an Enclosure as an attribute, this limitation is lifted, since we use an
existing html tag,
for example tr wicket:enclosure=child:label1, which gets naturally
rendered without
breaking the html. Also, the Enclosure as attribute doesn't get removed,
thus it can have state.
So now we have a stateful Enclosure enclosing a section of the html, and
it's visibility can be toggled
through ajax calls that toggle the visibility of it's designated child
object.
About the amount of boilerplate code to create an ajax-toggleable enclosure:
HTML: (excluding closing tags)
---
Before:
wicket:enclosure child=enclosureContainer:toggleable
tr wicket:id=enclosureContainer
..
After:
tr wicket:enclosure=child:toggleable
...
Java: (Excluding toggling mechanism)
--
Before:
WebMarkupContainer enclosureContainer = new
WebMarkupContainer(enclosureContainer){
@Override
public boolean isVisible() {
return get(toggleable).isVisible();
}
}).setOutputMarkupPlaceholderTag(true));
add(enclosureContainer);
..
After:
nothing, all this is automatic with the enclosure as attribute
..
- Joonas
On Sun, Feb 20, 2011 at 7:35 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
On Sat, Feb 19, 2011 at 2:20 PM, Juergen Donnerstag
juergen.donners...@gmail.com wrote:
A couple of comments on previous posts
- you can always assign your own wicket:id like wicket:enclosure
wicket:id=myEnclosure child=label1
- yes, wicket:enclosure creates an auto component (no java code
necessary) that is auto-added to the container which at that point in
time gets rendered, when during the render process the markup stream
hits the enclosure tag . And it gets automatically removed again which
means you can not have any state with it.
I looked at the patch and have a couple questions
It seems you try to achieve 2 very different things:
a) Changing the visibility of a child component in Ajax callback
method will not affect the entire enclosure but just the child
component itself. This is because only the child component is added to
the AjaxRequestTarget.
what is the limitation here? Enclosure checks the childComponent's
visibility before it renders the Enclosure. At the end that's the
whole idea of Enclosure. You never explicity change the Enclosure's
visibility. You always (with and without ajax) change the visibility
of the child component. Do I misunderstand something?
b) you prefer a wicket:enclosure attribute over a wicket:enclosure tag
you prefer div wicket:enclosure=child:label1 over
wicket:enclosure child=label1
Neither requires any java code. Neither is really longer or shorter
than the other. Neither requires more or less boilerplate. It seems to
me a matter of personal preference. That's up to the community what
you like. We can have either or both. I'm personally more in favour of
the tag, but that's of course only my opinion.
the problem with the tag is that it is not rendered into the markup so
cannot be targetted via ajax.
-igor
- Juergen
On Tue, Feb 8, 2011 at 7:34 AM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
i will try to look over it in the
Re: How to streamline ajax page region toggle
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 designer needs to know/assign, but it would be ok
to assign it in Java. With the additional benefit that an object
reference to the child can be used instead of a String (avoid rename
issues). You'd simply need to add a wicket:id to tr (instead of
wicket:enclosure) and to manually add a special component in Java (not
needed in your approach). A component similar to Enclosure in
behavior, but because it'll be added to the hierarchy with proper
child relationships (different than auto components), its
implementation would be much simpler (see EnclosureContainer in 1.5).
setOutputMarkupId() could be set automatically in the pre-render
phase. Finding the child enclosure would be as simple as walking up
the hierarchy - no magic at all. And different than the ART.Listener
I'd prefer an interface with a single callback which is invoked upon
adding a component (child) to the ART. ART would check the child and
all its parents for the interface to allow the Enclosure to add itself
as well.
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.
As I said, just a thought.
-Juergen
On Sun, Feb 20, 2011 at 5:16 PM, Juergen Donnerstag
juergen.donners...@gmail.com wrote:
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
may have many Panels. That wouldn't be a problem for Wicket because of
its hierarchy, but HTML IDs must be unique on the page.
Markup parsing / loading is completely decoupled from wickets
components hierarchy, there is no Page available. That linkage happens
in Resolvers. See the EnclosureResolver for an example.
- besides that I think its poor practice to introduce a dependency on
Enclosure in MarkupContainer, auto-added components must be removed
after the render process as you otherwise keep on adding new ones and
your are not freeing them up. I don't understand anyway why you did
this change, since Enclosure don't have any state.
- you added code to EnclosureHandler and EnclosureResolver and
Enclosure. Tinkering a bit with the code, I think having an
InlineEnclosureHandler and InlineEnclosure keeps them nicely separated
and thus cleaner. InlineEnclosureHandler has only very little in
common with EnclosureHandler and could be separate, whereas
InlineEnclosure is probably better derived from Enclosure.
-Juergen
On Sun, Feb 20, 2011 at 5:51 AM, Joo Hama joonas.hamalai...@gmail.com wrote:
the problem with the tag is that it is not rendered into the markup so
cannot be targetted via ajax.
-igor
Yes, this is exactly the point. We cannot render Enclosure tags without
breaking html,
for example inside a table. If we cannot render it, we cannot target it
with ajax. When we
use an Enclosure as an attribute, this limitation is lifted, since we use an
existing html tag,
for example tr wicket:enclosure=child:label1, which gets naturally
rendered without
breaking the html. Also, the Enclosure as attribute doesn't get removed,
thus it can have state.
So now we have a stateful Enclosure enclosing a section of the html, and
it's visibility can be toggled
through ajax calls that toggle the visibility of it's designated child
object.
About the amount of boilerplate code to create an ajax-toggleable enclosure:
HTML: (excluding closing tags)
---
Before:
wicket:enclosure child=enclosureContainer:toggleable
tr wicket:id=enclosureContainer
..
After:
tr wicket:enclosure=child:toggleable
...
Java: (Excluding toggling mechanism)
--
Before:
WebMarkupContainer enclosureContainer = new
WebMarkupContainer(enclosureContainer){
@Override
public boolean isVisible() {
return get(toggleable).isVisible();
}
}).setOutputMarkupPlaceholderTag(true));
add(enclosureContainer);
..
After:
nothing, all this is automatic with the enclosure as attribute
..
- Joonas
On Sun, Feb 20, 2011 at 7:35 AM, Igor Vaynberg
igor.vaynb...@gmail.comwrote:
On Sat, Feb 19, 2011 at 2:20 PM, Juergen Donnerstag
juergen.donners...@gmail.com wrote:
A couple of comments on previous posts
- you can always assign your own wicket:id like wicket:enclosure
wicket:id=myEnclosure child=label1
- yes, wicket:enclosure creates an auto component (no java code
necessary) that is auto-added to
Re: How to streamline ajax page region toggle
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 is to give the coder similar java-side
implementation for AJAX as there is for NON AJAX.
Without the current proposal, a non ajax implementor does not need to
care about enclosures when implementing on java-side. However, an ajax
implementor must do unnecessary of loops and hoops to accomplish just
the same thing.
We are trying to give the same freedom to the ajax-developer: not to
have to make boilerprate to implement eclosure behavior in ajax mode.
As I said, just a thought.
Did you try it out, the test cases etc. and how fly it is to use ajax
enclosures with it?
**
Martin
-Juergen
On Sun, Feb 20, 2011 at 5:16 PM, Juergen Donnerstag
juergen.donners...@gmail.com wrote:
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
may have many Panels. That wouldn't be a problem for Wicket because of
its hierarchy, but HTML IDs must be unique on the page.
Markup parsing / loading is completely decoupled from wickets
components hierarchy, there is no Page available. That linkage happens
in Resolvers. See the EnclosureResolver for an example.
- besides that I think its poor practice to introduce a dependency on
Enclosure in MarkupContainer, auto-added components must be removed
after the render process as you otherwise keep on adding new ones and
your are not freeing them up. I don't understand anyway why you did
this change, since Enclosure don't have any state.
- you added code to EnclosureHandler and EnclosureResolver and
Enclosure. Tinkering a bit with the code, I think having an
InlineEnclosureHandler and InlineEnclosure keeps them nicely separated
and thus cleaner. InlineEnclosureHandler has only very little in
common with EnclosureHandler and could be separate, whereas
InlineEnclosure is probably better derived from Enclosure.
-Juergen
On Sun, Feb 20, 2011 at 5:51 AM, Joo Hama joonas.hamalai...@gmail.com
wrote:
the problem with the tag is that it is not rendered into the markup so
cannot be targetted via ajax.
-igor
Yes, this is exactly the point. We cannot render Enclosure tags without
breaking html,
for example inside a table. If we cannot render it, we cannot target it
with ajax. When we
use an Enclosure as an attribute, this limitation is lifted, since we use an
existing html tag,
for example tr wicket:enclosure=child:label1, which gets naturally
rendered without
breaking the html. Also, the Enclosure as attribute doesn't get removed,
thus it can have state.
So now we have a stateful Enclosure enclosing a section of the html, and
it's visibility can be toggled
through ajax calls that toggle the visibility of it's designated child
object.
About the amount of boilerplate code to create an ajax-toggleable enclosure:
HTML: (excluding closing tags)
---
Before:
wicket:enclosure child=enclosureContainer:toggleable
tr wicket:id=enclosureContainer
..
After:
tr wicket:enclosure=child:toggleable
...
Java: (Excluding toggling mechanism)
--
Before:
WebMarkupContainer enclosureContainer = new
WebMarkupContainer(enclosureContainer){
@Override
public boolean isVisible() {
return get(toggleable).isVisible();
}
}).setOutputMarkupPlaceholderTag(true));
add(enclosureContainer);
..
After:
nothing, all this is automatic with the enclosure as attribute
..
- Joonas
On Sun, Feb 20, 2011 at 7:35 AM, Igor Vaynberg
igor.vaynb...@gmail.comwrote:
On Sat, Feb 19, 2011 at 2:20 PM, Juergen Donnerstag
juergen.donners...@gmail.com wrote:
A couple of comments on previous posts
- you can always assign your own wicket:id like wicket:enclosure
wicket:id=myEnclosure child=label1
- yes, wicket:enclosure creates an auto component (no java code
necessary) that is auto-added to the container which at that point in
time gets rendered, when during the render process the markup stream
hits the enclosure tag . And it gets automatically removed again which
means you can not have any state with it.
I looked at the patch and have a couple questions
It seems you try to achieve 2 very different things:
a) Changing the visibility of a child component in Ajax callback
method will not affect the entire enclosure but just the child
component itself. This is because only the child component is added to
the AjaxRequestTarget.
what is the limitation here? Enclosure checks the
[wicketstuff] core pom - not used dependencies
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 could they be removed? Attila
[vote] release wicket 1.4.16
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/orgapachewicket-031/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12316020 This vote ends Wednesday, February 23rd at 9:00am (GMT-8) Please test the release and offer your vote. -igor
[vote] release wicket 1.5-rc2
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.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12316059 This vote ends Wednesday, February 23 at 9:00am (GMT-8) Please test the release and offer your vote. -igor
Re: 1.4.16 - adding methods to IBehavior
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 jer...@wickettraining.com wrote: What does everyone think about the following patch [1] to add two methods to IBehavior? Obviously, it's not added directly to IBehavior since that would be a breaking API change. It's added to a sub-interface that can optionally be implemented by IBehaviors and is implemented by AbstractBehavior by default. It's for the purpose of allowing behaviors to contribute to things like the visibility and enabled status of a component, which they can't currently do in beforeRender because that happens during the render cycle, at which time such changes are not allowed. [1] - http://mysticpaste.com/view/8231 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: 1.4.16 - adding methods to IBehavior
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 checke...@gmail.comwrote: 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 jer...@wickettraining.com wrote: What does everyone think about the following patch [1] to add two methods to IBehavior? Obviously, it's not added directly to IBehavior since that would be a breaking API change. It's added to a sub-interface that can optionally be implemented by IBehaviors and is implemented by AbstractBehavior by default. It's for the purpose of allowing behaviors to contribute to things like the visibility and enabled status of a component, which they can't currently do in beforeRender because that happens during the render cycle, at which time such changes are not allowed. [1] - http://mysticpaste.com/view/8231 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [wicketstuff] core pom - not used dependencies
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 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 could they be removed? Attila -- Sent from my SMTP compliant software Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: 1.4.16 - adding methods to IBehavior
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: What does everyone think about the following patch [1] to add two methods to IBehavior? Obviously, it's not added directly to IBehavior since that would be a breaking API change. It's added to a sub-interface that can optionally be implemented by IBehaviors and is implemented by AbstractBehavior by default. It's for the purpose of allowing behaviors to contribute to things like the visibility and enabled status of a component, which they can't currently do in beforeRender because that happens during the render cycle, at which time such changes are not allowed. [1] - http://mysticpaste.com/view/8231 -- Sent from my SMTP compliant software Erik van Oosten http://day-to-day-stuff.blogspot.com/
