RE: Ideas on implementing dynamic addition of components that use AJAX?
Wow! That was a bit too easy!
Here's how to override onInitialize to dynamically add components to a
page that are specified in the markup:
protected void onInitialize()
{
super.onInitialize();
IMarkupFragment markupElements = getMarkup();
for (MarkupElement markupElement: markupElements)
{
if ( markupElement instanceof ComponentTag )
{
ComponentTag tag =
(ComponentTag)markupElement;
String tagId = tag.getId();
System.out.println("Markup Element: " +
tag.getName() + " ID: " + tagId);
if ( tagId != null )
{
if (
tagId.equals("systemPanel"))
{
add(new
SystemPanel("systemPanel"));
}
}
}
}
}
In this example "systemPanel" represents the ID of a single component
that should be added dynamically in onInitialize if it is discovered in
the markup.
It could be easily enhanced to support multiple dynamic components by
providing a set of IDs that represent components that should be
dynamically added and then add them when they are discovered during
onInitialize.
This could easily be applied to an application's Panel base class to
work inside Panels in addition to pages.
My only concern was that we're adding another iteration process to the
page construction cycle - iterating through all MarkupElements of the
markup of a component each time it's onInitialize is called but I guess
it's not that much of an issue. I was hoping to 'piggy back' the
processing onto some other process that is already iterating the markup
elements but I haven't found a suitable spot for that yet.
>-Original Message-
>From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
>Sent: Saturday, 24 November 2012 12:33 PM
>To: users@wicket.apache.org
>Subject: Re: Ideas on implementing dynamic addition of components that
use
>AJAX?
>
>On Thu, Nov 22, 2012 at 11:46 PM, Martin Grigorov
>wrote:
>> Hi,
>>
>>
>> On Fri, Nov 23, 2012 at 9:33 AM, Chris Colman
>> wrote:
>>
>>> >starting with wicket 1.5, however, components are able to resole
their
>>> >markup earlier in their lifecycle. the reason auto resolved
components
>>> >are added so late and treated specially was because the markup was
>>> >only available during render. if you are using 1.5 or 6 you can
build
>>> >your own mechanism. something that kicks off a page/panel's
>>> >oninitialize(), gets the markup, walks it, and adds any components
-
>>>
>>> Would it be walking the markup as raw XHTML or will parsed element
>>> objects be available at this point?
>>>
>>
>> You have to use #getMarkup() or #getAssociatedMarkup(), so the result
is
>> already parsed (IMarkupFragment).
>>
>>
>>>
>>> If it walks the markup will Wicket also be walking it at some time
later
>>> as well, kind of duplicating the markup walking process?
>>>
>>
>> Wicket walks the markup of the whole page for every render of the
page.
>> In Ajax requests only the markup of the repainted components is
>traversed.
>>
>>
>>>
>>> >maybe ones you mark by special tags in your own namespace. the
problem
>>> >here is that even if you can find these components you may still
not
>>> >be able to put them into the right parent because in onInitialize()
>>> >the parent may not yet be added to the container. so perhaps you
>>>
>>
>> I think this is not correct. In #onInitialize() you have access to
the
>> markup of the current component and access to the Page instance, i.e.
you
>> have access to all parents between the current component and the Page
>> instance.
>
>it is correct. i am not talking about the component on which
>onInitialize() is being called... suppose you have a page that
>implements the mechanism and your markup is like this:
>
>
>
>what i meant is that inside the page's onInitialize() the component
>"foo" may not have yet been added so the wicket:something component
>cannot be properly put into it
>
>in this case the page's subclass' onInitialize() may add "foo" or
>onConfigure() can add "foo" or some other component if the hierarchy
>is deeper.
>
>-igor
>
>>
>>
>>> >should have some mechanism that kicks off when
page#onComponentAdded()
>>> >is called. you can pull the newly added component's markup, see if
it
>>> >has any of these special components defined as a child of the
>>> >components markup, and add them right there. since you are doing
this
>>> >early on these components will have normal lifecycle and should
work
>>> >just like any other component.
>>> >
>>> >hope this helps you get started. keep us in the loop.
>>>
>>> Sounds so crazy that it just might work ;)
>>>
>>> >
>>
Re: Updating datatable ajax
I stand corrected as I missed one of your replies. I see now that you're using Ajax and you have a drop down of which value you would like to append an extra row to your table. Yes, keep the list in memory if its small enough and add the enter in the correct place and the refresh the table via Ajax. As long as your data provider manipulates the same list it should work just fine. If you want code examples let me know, I have plenty of those add new editable rows. Have a great day, Paul Bors On Nov 24, 2012, at 1:03 AM, "Paul Borș" wrote: > Silly question, but do you refresh the table either via Ajax or a page > refresh by sending a parameter of your data provider through a constructor or > something? > > Because simply manipulating the data provider will no magically redraw things > on the screen :) > > Put a log or break in your data provider and see it for your self. > > Have a great day, > Paul Bors > > On Nov 20, 2012, at 6:21 PM, anton wrote: > >> help please >> >> >> >> -- >> View this message in context: >> http://apache-wicket.1842946.n4.nabble.com/Updating-datatable-ajax-tp4653734p4654051.html >> Sent from the Users forum mailing list archive at Nabble.com. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Updating datatable ajax
Silly question, but do you refresh the table either via Ajax or a page refresh by sending a parameter of your data provider through a constructor or something? Because simply manipulating the data provider will no magically redraw things on the screen :) Put a log or break in your data provider and see it for your self. Have a great day, Paul Bors On Nov 20, 2012, at 6:21 PM, anton wrote: > help please > > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Updating-datatable-ajax-tp4653734p4654051.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.5.8 + EJB 3.1 - strange problem
Why don't you instead use a bigger and more robust IoC framework like Spring and a persistence framework you can trust like Hibernate? Check out: http://wicketinaction.com/2009/06/wicketspringhibernate-configuration/ Have a great day, Paul Bors On Nov 19, 2012, at 8:39 AM, Satrix wrote: > Nope. Look at the example: > > 1. User has chose to add a product to the Cart (so now the cart number is 1 > and he can see that number in a proper place on the page). > > 2. Now when he clicks back button - bean is recreated - so the cart number > is 0 (list is recreated). > > 3. BUT now when I click on any other link on my page container returns > previous EJB bean so the cart number is 1. > > Btw Im using LoadableDetachableModel so there is no way that the user is > seeing stale data. > > Regards, Satrix > > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Wicket-1-5-8-EJB-3-1-strange-problem-tp4653977p4653995.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org >
WicketTagIdentifier: possible optimization
Just looking at the Wicket source for an unrelated issue I noticed that
WicketTagIdentifier stores a private static collection of
wellKnownTagNames as an ArrayList.
and a method called isWellKnown is called from within
WicketTagIdentifier.onComponentTag and presumably it's called on every
Wicket tag parsed.
private boolean isWellKnown(final ComponentTag tag)
{
for (String name : wellKnownTagNames)
{
if
(tag.getName().equalsIgnoreCase(name))
{
return true;
}
}
return false;
}
This method iterates over the list elements until an item is found so
has O(n) performance. If this array list was to be changed to a Set
instead it would have O(1) performance.
I haven't got any metrics on the usage and I don't think the improvement
would be sensational but for web apps with large quantities of markup it
could make some difference. For such a simple change it's probably worth
it.
Re: Ideas on implementing dynamic addition of components that use AJAX?
On Thu, Nov 22, 2012 at 11:46 PM, Martin Grigorov wrote: > Hi, > > > On Fri, Nov 23, 2012 at 9:33 AM, Chris Colman > wrote: > >> >starting with wicket 1.5, however, components are able to resole their >> >markup earlier in their lifecycle. the reason auto resolved components >> >are added so late and treated specially was because the markup was >> >only available during render. if you are using 1.5 or 6 you can build >> >your own mechanism. something that kicks off a page/panel's >> >oninitialize(), gets the markup, walks it, and adds any components - >> >> Would it be walking the markup as raw XHTML or will parsed element >> objects be available at this point? >> > > You have to use #getMarkup() or #getAssociatedMarkup(), so the result is > already parsed (IMarkupFragment). > > >> >> If it walks the markup will Wicket also be walking it at some time later >> as well, kind of duplicating the markup walking process? >> > > Wicket walks the markup of the whole page for every render of the page. > In Ajax requests only the markup of the repainted components is traversed. > > >> >> >maybe ones you mark by special tags in your own namespace. the problem >> >here is that even if you can find these components you may still not >> >be able to put them into the right parent because in onInitialize() >> >the parent may not yet be added to the container. so perhaps you >> > > I think this is not correct. In #onInitialize() you have access to the > markup of the current component and access to the Page instance, i.e. you > have access to all parents between the current component and the Page > instance. it is correct. i am not talking about the component on which onInitialize() is being called... suppose you have a page that implements the mechanism and your markup is like this: what i meant is that inside the page's onInitialize() the component "foo" may not have yet been added so the wicket:something component cannot be properly put into it in this case the page's subclass' onInitialize() may add "foo" or onConfigure() can add "foo" or some other component if the hierarchy is deeper. -igor > > >> >should have some mechanism that kicks off when page#onComponentAdded() >> >is called. you can pull the newly added component's markup, see if it >> >has any of these special components defined as a child of the >> >components markup, and add them right there. since you are doing this >> >early on these components will have normal lifecycle and should work >> >just like any other component. >> > >> >hope this helps you get started. keep us in the loop. >> >> Sounds so crazy that it just might work ;) >> >> > >> >-igor >> > >> > >> >On Thu, Nov 22, 2012 at 4:54 PM, Chris Colman >> > wrote: >> >> We've been using Wicket since version 1.3 and have been using the >> >> IComponentResolver interface with great effect to allow the web >> >> designers to effectively 'plug and play' with the Wicket components. >> >> >> >> We have multiple layouts using Wicket's 'variation' feature. Each >> >> designer can build up a different collection of components in any >> >> particular variation as they like - all without changing the Java >> code. >> >> >> >> Normally, without using IComponentResolver, the Java code to support >> >> such flexibility would be mind boggingly complex and ugly but with an >> >> IComponentResolver we simply have code that's capable of >> instantiating >> >> any component anywhere - and it works and the resulting code is >> >> extremely elegant. >> >> >> >> While we use lots of AJAX it is restricted to components that are >> >> explicitly added to components i.e. not added dynamically via the >> >> component resolver because such components are not able to contribute >> >> anything to the section. >> >> >> >> This is starting to become a bit of a problem as we want some of the >> >> more advanced components (with AJAX) to take part in the 'plug and >> play' >> >> flexibility. We also are starting to get into using Twitter Bootstrap >> >> with Wicket and much of the 'funkiness' in some of those components >> >> comes from JS that needs to be injected into the header. >> >> >> >> Is anyone else using this 'plug and play' capability of Wicket made >> >> available via the IComponentResolver interface or is everyone >> sticking >> >> to the rigid 1 to 1 relationship between markup and the corresponding >> >> statically coded Java component hierarchy? (which we found quite >> >> constricting after a few weeks =] ) >> >> >> >> I understand that there are some workarounds suggested for empowering >> >> AJAX in dynamically added components but they seem to involve >> manually >> >> parsing markup in the onInitialize method and then explicitly adding >> any >> >> required components there - it sounds non ideal and would result in >> an >> >> extra parse of all page and panel markups I would think - which may >> >> affect performance. Would we be parsing raw XHTML at that stage or >> would >> >> a preparsed DOM b
Re: DropDownChoice.setNullValid
Are you confusing nullValid w/ nullAllowed? ~ Thank you, Paul Bors On Nov 14, 2012, at 5:43 PM, Nick Pratt wrote: > As a followup - if you dont pass the null in the choices list, then it > works as expected. > > > On Wed, Nov 14, 2012 at 5:35 PM, Nick Pratt wrote: > >> public List choices = Arrays.asList(null,"RENDER","ENABLE"); >> DropDownChoice defaultPerm = new DropDownChoice<>( "perm", >> permModel, choices ); >> defaultPerm.setNullValid( true ); >> >> When this renders, I see a select box with 4 options - 2 blanks, and the >> two text options. >> I expected to only see three - a blank (null) and the two text options. >> >> Is this expected behavior? (Wicket 6.2) >> >> >> Nick >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: File download through form submit & feedback messages
juhar wrote:
> Hi,
>
> I have a page with a form on it. After the user has submitted the form
> successfully (all the fields have validated ok), the server creates a
> report-file based on the form values. The file is not created as physical
> file on the server, but it is given as download to the user.
>
> Now, if the user first fills the form incorrectly, there are validator
> feedback messages shown. If the user then submits the form with correct
> values, the problem is that previous feedback error messages are not
> cleared. I can't also create a new feedback message saying something like
> "The report was created successfully." The file download response prevents
> any updating of the current page.
>
Have you tried to use a resource link with
a) an AJAX action to update your page
b) a Call-Decorator that adds "return true" to the onclick-Event.
That causes the genuine Resource-Link-Action to be done which
initiate a download.
c) Maybe also use target="_blank" in your Link-HTML. If there are
errors in your download code, you can arrange to show them in a
new situation-specific error page.
Something like:
final ResourceLink downloadPDF = new
ResourceLink("downloadPDF", pdfResource);
downloadPDF.add(new AjaxEventBehavior ("onclick") {
private static final long serialVersionUID = 1L;
@Override protected void onEvent (AjaxRequestTarget target) {
// update actions for page go here
}
@Override protected IAjaxCallDecorator getAjaxCallDecorator() {
return new AjaxCallDecorator() {
private static final long serialVersionUID = 1L;
@Override public CharSequence decorateScript(CharSequence script) {
return script+"return true;";
}
};
}
});
This is working 1.4 code (it has to run on JBoss 4, I can't use 1.5ff),
no problems with IE8. (pdfResource is a WebResource-subclass object that
actually generates a PDF document.) IAjaxCallDecorator is gone in Wicket 6,
but there is a replacement for it; that was mentioned on this list
recently.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod, Roedermark, Germany
Email: jsch...@acm.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Force Ajax onClick event on empty
On Fri, Nov 23, 2012 at 4:22 PM, Nick Pratt wrote:
> Try putting a non-breaking space in there:
>
>
>
And then only this space character will be clickable.
Better wrap the in :
...
>
>
> On Fri, Nov 23, 2012 at 6:41 AM, wrote:
>
> > Hi all
> >
> > I seem to struggle more than expected on this scenario: An empty tag
> > wont trigger Ajax
> >
> > HTML is pretty simple
> >
> > >
> href="../page?3-2.ILinkListener-navigation-navigation_body-wmc-left-4-comp-content-tabs-panel-body-rows-5-cells-2-cell-3-link"
> > id="link17a">
> >
> >
> >
> > myIcon {
> > background: url("../img/myImg.png");
> >
> > Whats the trick? should I use some transparent text approach or? any
> > experiences here to share?
> >
> > Thanks in advance!
> >
> > /Ronny
> >
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Force Ajax onClick event on empty
Try putting a non-breaking space in there:
On Fri, Nov 23, 2012 at 6:41 AM, wrote:
> Hi all
>
> I seem to struggle more than expected on this scenario: An empty tag
> wont trigger Ajax
>
> HTML is pretty simple
>
> href="../page?3-2.ILinkListener-navigation-navigation_body-wmc-left-4-comp-content-tabs-panel-body-rows-5-cells-2-cell-3-link"
> id="link17a">
>
>
>
> myIcon {
> background: url("../img/myImg.png");
>
> Whats the trick? should I use some transparent text approach or? any
> experiences here to share?
>
> Thanks in advance!
>
> /Ronny
>
Re: Force Ajax onClick event on empty
Ajax works also with empty tags, but your link does not receive click events
because of the surrounding span (which gets the click events).
Try this:
.myIcon {
background: url("...");
display: inline-block;
height: XXXpx;
width: YYYpx;
}
Cheers,
-Tom
On 23.11.2012, at 12:41, ronny.v...@consult.nordea.com wrote:
> Hi all
>
> I seem to struggle more than expected on this scenario: An empty tag wont
> trigger Ajax
>
> HTML is pretty simple
>
> href="../page?3-2.ILinkListener-navigation-navigation_body-wmc-left-4-comp-content-tabs-panel-body-rows-5-cells-2-cell-3-link"
> id="link17a">
>
>
>
> myIcon {
>background: url("../img/myImg.png");
>
> Whats the trick? should I use some transparent text approach or? any
> experiences here to share?
>
> Thanks in advance!
>
> /Ronny
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Force Ajax onClick event on empty
Hi all
I seem to struggle more than expected on this scenario: An empty tag wont
trigger Ajax
HTML is pretty simple
myIcon {
background: url("../img/myImg.png");
Whats the trick? should I use some transparent text approach or? any
experiences here to share?
Thanks in advance!
/Ronny
Re: Ideas on implementing dynamic addition of components that use AJAX?
See IMarkupFilter implementations. On Fri, Nov 23, 2012 at 12:08 PM, Chris Colman wrote: > I had a thought - is there an interface implemented that provides the > parsing of markup? If there was then I could somehow hook into that or > provide another implementation and avoid double parsing of the markup - > or would that be happening too late in the lifecycle to work? > > > -Original Message- > > From: Martin Grigorov [mailto:mgrigo...@apache.org] > > Sent: Friday, 23 November 2012 6:47 PM > > To: users@wicket.apache.org > > Subject: Re: Ideas on implementing dynamic addition of components that > use > > AJAX? > > > > Hi, > > > > > > On Fri, Nov 23, 2012 at 9:33 AM, Chris Colman > > wrote: > > > > > >starting with wicket 1.5, however, components are able to resole > their > > > >markup earlier in their lifecycle. the reason auto resolved > components > > > >are added so late and treated specially was because the markup was > > > >only available during render. if you are using 1.5 or 6 you can > build > > > >your own mechanism. something that kicks off a page/panel's > > > >oninitialize(), gets the markup, walks it, and adds any components > - > > > > > > Would it be walking the markup as raw XHTML or will parsed element > > > objects be available at this point? > > > > > > > You have to use #getMarkup() or #getAssociatedMarkup(), so the result > is > > already parsed (IMarkupFragment). > > > > > > > > > > If it walks the markup will Wicket also be walking it at some time > later > > > as well, kind of duplicating the markup walking process? > > > > > > > Wicket walks the markup of the whole page for every render of the > page. > > In Ajax requests only the markup of the repainted components is > traversed. > > > > > > > > > > >maybe ones you mark by special tags in your own namespace. the > problem > > > >here is that even if you can find these components you may still > not > > > >be able to put them into the right parent because in onInitialize() > > > >the parent may not yet be added to the container. so perhaps you > > > > > > > I think this is not correct. In #onInitialize() you have access to the > > markup of the current component and access to the Page instance, i.e. > you > > have access to all parents between the current component and the Page > > instance. > > > > > > > >should have some mechanism that kicks off when > page#onComponentAdded() > > > >is called. you can pull the newly added component's markup, see if > it > > > >has any of these special components defined as a child of the > > > >components markup, and add them right there. since you are doing > this > > > >early on these components will have normal lifecycle and should > work > > > >just like any other component. > > > > > > > >hope this helps you get started. keep us in the loop. > > > > > > Sounds so crazy that it just might work ;) > > > > > > > > > > >-igor > > > > > > > > > > > >On Thu, Nov 22, 2012 at 4:54 PM, Chris Colman > > > > wrote: > > > >> We've been using Wicket since version 1.3 and have been using the > > > >> IComponentResolver interface with great effect to allow the web > > > >> designers to effectively 'plug and play' with the Wicket > components. > > > >> > > > >> We have multiple layouts using Wicket's 'variation' feature. Each > > > >> designer can build up a different collection of components in any > > > >> particular variation as they like - all without changing the Java > > > code. > > > >> > > > >> Normally, without using IComponentResolver, the Java code to > support > > > >> such flexibility would be mind boggingly complex and ugly but > with an > > > >> IComponentResolver we simply have code that's capable of > > > instantiating > > > >> any component anywhere - and it works and the resulting code is > > > >> extremely elegant. > > > >> > > > >> While we use lots of AJAX it is restricted to components that are > > > >> explicitly added to components i.e. not added dynamically via the > > > >> component resolver because such components are not able to > contribute > > > >> anything to the section. > > > >> > > > >> This is starting to become a bit of a problem as we want some of > the > > > >> more advanced components (with AJAX) to take part in the 'plug > and > > > play' > > > >> flexibility. We also are starting to get into using Twitter > Bootstrap > > > >> with Wicket and much of the 'funkiness' in some of those > components > > > >> comes from JS that needs to be injected into the header. > > > >> > > > >> Is anyone else using this 'plug and play' capability of Wicket > made > > > >> available via the IComponentResolver interface or is everyone > > > sticking > > > >> to the rigid 1 to 1 relationship between markup and the > corresponding > > > >> statically coded Java component hierarchy? (which we found quite > > > >> constricting after a few weeks =] ) > > > >> > > > >> I understand that there are some workarounds suggested for > empowering > > > >> AJAX in dynamically added c
RE: Ideas on implementing dynamic addition of components that use AJAX?
I had a thought - is there an interface implemented that provides the parsing of markup? If there was then I could somehow hook into that or provide another implementation and avoid double parsing of the markup - or would that be happening too late in the lifecycle to work? > -Original Message- > From: Martin Grigorov [mailto:mgrigo...@apache.org] > Sent: Friday, 23 November 2012 6:47 PM > To: users@wicket.apache.org > Subject: Re: Ideas on implementing dynamic addition of components that use > AJAX? > > Hi, > > > On Fri, Nov 23, 2012 at 9:33 AM, Chris Colman > wrote: > > > >starting with wicket 1.5, however, components are able to resole their > > >markup earlier in their lifecycle. the reason auto resolved components > > >are added so late and treated specially was because the markup was > > >only available during render. if you are using 1.5 or 6 you can build > > >your own mechanism. something that kicks off a page/panel's > > >oninitialize(), gets the markup, walks it, and adds any components - > > > > Would it be walking the markup as raw XHTML or will parsed element > > objects be available at this point? > > > > You have to use #getMarkup() or #getAssociatedMarkup(), so the result is > already parsed (IMarkupFragment). > > > > > > If it walks the markup will Wicket also be walking it at some time later > > as well, kind of duplicating the markup walking process? > > > > Wicket walks the markup of the whole page for every render of the page. > In Ajax requests only the markup of the repainted components is traversed. > > > > > > >maybe ones you mark by special tags in your own namespace. the problem > > >here is that even if you can find these components you may still not > > >be able to put them into the right parent because in onInitialize() > > >the parent may not yet be added to the container. so perhaps you > > > > I think this is not correct. In #onInitialize() you have access to the > markup of the current component and access to the Page instance, i.e. you > have access to all parents between the current component and the Page > instance. > > > > >should have some mechanism that kicks off when page#onComponentAdded() > > >is called. you can pull the newly added component's markup, see if it > > >has any of these special components defined as a child of the > > >components markup, and add them right there. since you are doing this > > >early on these components will have normal lifecycle and should work > > >just like any other component. > > > > > >hope this helps you get started. keep us in the loop. > > > > Sounds so crazy that it just might work ;) > > > > > > > >-igor > > > > > > > > >On Thu, Nov 22, 2012 at 4:54 PM, Chris Colman > > > wrote: > > >> We've been using Wicket since version 1.3 and have been using the > > >> IComponentResolver interface with great effect to allow the web > > >> designers to effectively 'plug and play' with the Wicket components. > > >> > > >> We have multiple layouts using Wicket's 'variation' feature. Each > > >> designer can build up a different collection of components in any > > >> particular variation as they like - all without changing the Java > > code. > > >> > > >> Normally, without using IComponentResolver, the Java code to support > > >> such flexibility would be mind boggingly complex and ugly but with an > > >> IComponentResolver we simply have code that's capable of > > instantiating > > >> any component anywhere - and it works and the resulting code is > > >> extremely elegant. > > >> > > >> While we use lots of AJAX it is restricted to components that are > > >> explicitly added to components i.e. not added dynamically via the > > >> component resolver because such components are not able to contribute > > >> anything to the section. > > >> > > >> This is starting to become a bit of a problem as we want some of the > > >> more advanced components (with AJAX) to take part in the 'plug and > > play' > > >> flexibility. We also are starting to get into using Twitter Bootstrap > > >> with Wicket and much of the 'funkiness' in some of those components > > >> comes from JS that needs to be injected into the header. > > >> > > >> Is anyone else using this 'plug and play' capability of Wicket made > > >> available via the IComponentResolver interface or is everyone > > sticking > > >> to the rigid 1 to 1 relationship between markup and the corresponding > > >> statically coded Java component hierarchy? (which we found quite > > >> constricting after a few weeks =] ) > > >> > > >> I understand that there are some workarounds suggested for empowering > > >> AJAX in dynamically added components but they seem to involve > > manually > > >> parsing markup in the onInitialize method and then explicitly adding > > any > > >> required components there - it sounds non ideal and would result in > > an > > >> extra parse of all page and panel markups I would think - which may > > >> affect performance. Would we be parsing raw XHTML at th
Re: Wicket CryptoMapper loses RequestParameters for HomePage (1.5-SNAPSHOT)
Jesse, thanks for fixing this in Wicket 6.3.0!
https://issues.apache.org/jira/browse/WICKET-4865
On Mon, Nov 5, 2012 at 10:50 PM, matmar [via Apache Wicket] <
ml-node+s1842946n4653637...@n4.nabble.com> wrote:
> Hi!
>
> We have a problem with using CryptoMapper, and a proposed fix. I'd like
> some comments from this community regarding both the bug and the fix.
>
> When CryptoMapper is used, query parameters are only found via
> PageParameters, and not via RequestParameters, as expected.
>
> Code to repro:
> --code-
> HomePage.java
>
> public HomePage(final PageParameters parameters) {
> add(new Label("version",
> getApplication().getFrameworkSettings().getVersion()));
> add(new Label("fooFromPageParameters",
> parameters.get("foo").toString("NOT_FOUND_FROM_PAGE_PARAMETERS")));
> add(new Label("fooFromRequestParameters",
> getRequest().getRequestParameters().getParameterValue("foo").toString("NOT_FOUND_FROM_REQUEST_PARAMETERS")));
>
> }
>
> HomePage.html
>
>
> Congratulations! Wicket
> version: wicket:id="version">1.5-SNAPSHOT
> Foo from Page parameters: wicket:id="fooFromPageParameters">fooFromPageParametes
> Foo from request parameters: wicket:id="fooFromRequestParameters">fooFromRequestParameters
>
>
> WicketApplication.java
>
>public void init()
>{
> super.init();
> //comment to get both parameters working
> setRootRequestMapper(new
> CryptoMapper(getRootRequestMapper(), this));
>
>}
>
> When called with url http://localhost:8080/?foo=bar, and CryptoMapper is
> enabled, the value for foo is not found via requestParameters.
>
> code---
>
> And then the proposed fix:
> http://pastebin.com/dWdPhcLD
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-wicket.1842946.n4.nabble.com/Wicket-CryptoMapper-loses-RequestParameters-for-HomePage-1-5-SNAPSHOT-tp4653637.html
> This email was sent by
> matmar(via
> Nabble)
> To receive all replies by email, subscribe to this
> discussion
>
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Wicket-CryptoMapper-loses-RequestParameters-for-HomePage-1-5-SNAPSHOT-tp4653637p4654110.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RE: Ideas on implementing dynamic addition of components that use AJAX?
>historically the components you add from auto resolvers are added via >the autoAdd() method, not using add(). these components only exist >during render of the page (in detach() phase all auto-added components >are removed). the thinking here is that auto resolved components are >not normal components. because they are resolved so late in the >lifecycle they do not typically implement the entire lifecycle like >onInitialize(), onConfigure(), etc may not necessarily be called. such >components are also not meant to have their own state. because of >these reasons we remove them at the end of the request and readd a new >instance next time the page is rendered. these are basically >"transient" "render-once" components. I understand the historical treatment of components added by a component resolver but would it work if there was, say, a mechanism whereby we could set a flag on certain components that are added by a component resolver to tell Wicket to treat them like first class components instead of treating them like second class components like it does now? In other words they would be treated as if they were added explicitly to their parent in the contructor or onInitialize. i.e. preserved on detach etc., - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
