RE: Ideas on implementing dynamic addition of components that use AJAX?

2012-11-23 Thread Chris Colman
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



Re: Wicket CryptoMapper loses RequestParameters for HomePage (1.5-SNAPSHOT)

2012-11-23 Thread matmar
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

   div id=bd
  Congratulations! pWicket
 version: wicket:container
 wicket:id=version1.5-SNAPSHOT/wicket:container/p
  pFoo from Page parameters: wicket:container
 wicket:id=fooFromPageParametersfooFromPageParametes/wicket:container/p
  pFoo from request parameters: wicket:container
 wicket:id=fooFromRequestParametersfooFromRequestParameters/wicket:container/p
   /div

 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 
 matmarhttp://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=user_nodesuser=99626(via
  Nabble)
 To receive all replies by email, subscribe to this 
 discussionhttp://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=subscribe_by_codenode=4653637code=bWFyY3VzLm1hdHRpbGFAZ21haWwuY29tfDQ2NTM2Mzd8LTg4NDY3MDUxNg==





--
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?

2012-11-23 Thread Chris Colman
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
 chr...@stepaheadsoftware.comwrote:
 
  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
  chr...@stepaheadsoftware.com 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 head 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 be available to search through?
  
   What is the fundamental issue with the Wicket architecture that
  prevents
   dynamically resolved components from contributing to the header?
  
   Is 

Re: Ideas on implementing dynamic addition of components that use AJAX?

2012-11-23 Thread Martin Grigorov
See IMarkupFilter implementations.


On Fri, Nov 23, 2012 at 12:08 PM, Chris Colman chr...@stepaheadsoftware.com
 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
  chr...@stepaheadsoftware.comwrote:
 
   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
   chr...@stepaheadsoftware.com 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 head 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 

Force Ajax onClick event on empty a

2012-11-23 Thread Ronny.Voss
Hi all

I seem to struggle more than expected on this scenario: An empty A tag wont 
trigger Ajax

HTML is pretty simple
span class=myIcon  id=id3192
a 
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
/a
/span

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 a

2012-11-23 Thread Thomas Götz
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:

a wicket:id=link class=myIcon/a

.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 A tag wont 
 trigger Ajax
 
 HTML is pretty simple
 span class=myIcon  id=id3192
 a 
 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
 /a
 /span
 
 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



Re: Force Ajax onClick event on empty a

2012-11-23 Thread Nick Pratt
Try putting a non-breaking space in there:

anbsp;/a


On Fri, Nov 23, 2012 at 6:41 AM, ronny.v...@consult.nordea.com wrote:

 Hi all

 I seem to struggle more than expected on this scenario: An empty A tag
 wont trigger Ajax

 HTML is pretty simple
 span class=myIcon  id=id3192
 a
 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
 /a
 /span

 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 a

2012-11-23 Thread Martin Grigorov
On Fri, Nov 23, 2012 at 4:22 PM, Nick Pratt nbpr...@gmail.com wrote:

 Try putting a non-breaking space in there:

 anbsp;/a


And then only this space character will be clickable.
Better wrap the span in a:

a ...span.../span/a




 On Fri, Nov 23, 2012 at 6:41 AM, ronny.v...@consult.nordea.com wrote:

  Hi all
 
  I seem to struggle more than expected on this scenario: An empty A tag
  wont trigger Ajax
 
  HTML is pretty simple
  span class=myIcon  id=id3192
  a
 
 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
  /a
  /span
 
  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 http://jweekend.com/


Re: File download through form submit feedback messages

2012-11-23 Thread Joachim Schrod
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 ResourceLinkObject downloadPDF = new 
ResourceLinkObject(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: DropDownChoice.setNullValid

2012-11-23 Thread Paul Borș
Are you confusing nullValid w/ nullAllowed?

~ Thank you,
   Paul Bors

On Nov 14, 2012, at 5:43 PM, Nick Pratt nbpr...@gmail.com 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 nbpr...@gmail.com wrote:
 
 public ListString choices = Arrays.asList(null,RENDER,ENABLE);
 DropDownChoiceString 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



WicketTagIdentifier: possible optimization

2012-11-23 Thread Chris Colman
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: Wicket 1.5.8 + EJB 3.1 - strange problem

2012-11-23 Thread Paul Borș
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 satrix...@gmail.com 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
 


Re: Updating datatable ajax

2012-11-23 Thread Paul Borș
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 antoniovalenciasp...@hotmail.com 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

2012-11-23 Thread Paul Borș
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ș p...@bors.ws 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 antoniovalenciasp...@hotmail.com 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: Ideas on implementing dynamic addition of components that use AJAX?

2012-11-23 Thread Chris Colman
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
mgrigo...@apache.org
wrote:
 Hi,


 On Fri, Nov 23, 2012 at 9:33 AM, Chris Colman
 chr...@stepaheadsoftware.comwrote:

 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:

bodydiv wicket:id=foowicket:something//div

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
 chr...@stepaheadsoftware.com wrote:
  We've been using