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

2012-11-22 Thread Martin Grigorov
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 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 one of the causes the fact that by the time the ComponentResolver
> is
> >> being called the header has already been rendered to the response
> stream
> >> and so once body rendering commences no more header injection is
> >> possible?
> >>
> >> If so, that could probably (thinking out aloud without an in depth
> >> knowledge of Wicket's internals =] ) be solved by splitting the
> >> rendering into two streams: header injection goes to current output
> >> stream while body renderi

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

2012-11-22 Thread Sven Meier

The markup is parsed already, see Component#getMarkup().

Sven

On 11/23/2012 08: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?

If it walks the markup will Wicket also be walking it at some time later
as well, kind of duplicating the markup walking process?


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
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 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 one of the causes the fact that by the time the ComponentResolver

is

being called the header has already been rendered to the response

stream

and so once body rendering commences no more header injection is
possible?

If so, that could probably (thinking out aloud without an in depth
knowledge of Wicket's internals =] ) be solved by splitting the
rendering into two streams: header injection goes to current output
stream while body rendering goes to a temporary 'body' stream. When

the

page render is complete the output of the body is then appended to

the

current stream, after the header rendering. This would allow header
injection to continue during processing of the body markup because

both

are not being sequentially output to the same stream.

There was mention of another issue - something about auto added
(component resolver) objects being removed after rendering so they

are

not there when AJAX actions occur. I don't fully understand the

details

of this or why it is necessary. Maybe this devs could offer more

advice

on this.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail:

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

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

If it walks the markup will Wicket also be walking it at some time later
as well, kind of duplicating the markup walking process?

>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
>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 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 one of the causes the fact that by the time the ComponentResolver
is
>> being called the header has already been rendered to the response
stream
>> and so once body rendering commences no more header injection is
>> possible?
>>
>> If so, that could probably (thinking out aloud without an in depth
>> knowledge of Wicket's internals =] ) be solved by splitting the
>> rendering into two streams: header injection goes to current output
>> stream while body rendering goes to a temporary 'body' stream. When
the
>> page render is complete the output of the body is then appended to
the
>> current stream, after the header rendering. This would allow header
>> injection to continue during processing of the body markup because
both
>> are not being sequentially output to the same stream.
>>
>> There was mention of another issue - something about auto added
>> (component resolver) objects being removed after rendering so they
are
>> not there when AJAX actions occur. I don't fully understand the
details
>> of this or why it is necessary. Maybe this devs could offer more
advice
>> on this.
>
>-
>To unsubscribe, e-mail: users-unsubsc

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

2012-11-22 Thread Igor Vaynberg
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.

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

-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 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 one of the causes the fact that by the time the ComponentResolver is
> being called the header has already been rendered to the response stream
> and so once body rendering commences no more header injection is
> possible?
>
> If so, that could probably (thinking out aloud without an in depth
> knowledge of Wicket's internals =] ) be solved by splitting the
> rendering into two streams: header injection goes to current output
> stream while body rendering goes to a temporary 'body' stream. When the
> page render is complete the output of the body is then appended to the
> current stream, after the header rendering. This would allow header
> injection to continue during processing of the body markup because both
> are not being sequentially output to the same stream.
>
> There was mention of another issue - something about aut

Implementing channels in wicket-atmosphere

2012-11-22 Thread Pierre Goupil
Good evening,

I've just filled in an enhancement request for wicket-atmosphere :

https://issues.apache.org/jira/browse/WICKET-4879

I'd be more than happy to help for it as much as I can, if Emond feels
inclined to work on that.

Hope to hear from you, guys.

Regards,

Pierre



-- 
Le bonheur n'est pas une destination, mais une façon de voyager.

Papa d'une petite Lou-Ann depuis le 30 juin.


Re: Manual procedure to update Wicket for NetBeans

2012-11-22 Thread Ian Marshall
Martin Grigorov-4 wrote
> [...]
> 
> You can check http://ant.apache.org/ivy/. It adds dependency management to
> Ant.
> 
> -- 
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com ;

Thanks for the tip, Martin. I'll give Apache Ivy a look

Ian



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Manual-procedure-to-update-Wicket-for-NetBeans-tp4654064p4654096.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: How important is detaching models really ?

2012-11-22 Thread Chris Colman
I guess in more complex apps the UI elements end up with lots of
references to model objects so detaching does save a lot of memory and
it also makes transferring session data from one web server to another
(if required) in a multi server environment, much more efficient. I have
experienced the result of accidentally serializing an object graph with
megabytes of data that didn't use detach - ouch!

The other benefit of detaching is your model will expose updates to the
UI (if a redisplay occurred) that were made in other ORM sessions
(depending on your ORM). Keeping a non detached copy of the model object
will typically be like caching it in it's current state for most ORMs -
i.e. it can get stale

>-Original Message-
>From: tobi [mailto:tobias.gie...@code-sourcery.de]
>Sent: Thursday, 22 November 2012 9:10 PM
>To: users@wicket.apache.org
>Subject: How important is detaching models really ?
>
>Hi guys,
>
> From my understanding & experiments with Wicket's built-in session
>inspector , detaching models seems to just affect the size of the page
>store (and of course cut-down the amount of I/O required for
serializing
>the object graph). The session size shown on my pages is a constantly
>low value (<1k , we're storing nothing except the currently logged-in
>user).
>
>So it *seems* not detaching models has no effect on the (long-term)
>memory footprint of a Wicket application.
>
>According to
>https://cwiki.apache.org/WICKET/working-with-wicket-models.html , not
>detaching models should affect the session size but at least looking at
>the inspector I can't see this. Is the wiki article still correct / the
>inspector not telling the truth ?
>
>Thanks,
>Tobias
>
>P.S. I'm using Wicket 1.5.8 btw
>
>-
>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: Manual procedure to update Wicket for NetBeans

2012-11-22 Thread Sébastien Gautrin
For your exact situation, I suppose the maven-gae-plugin 
(https://github.com/maven-gae-plugin/maven-gae-plugin ) will solve your 
problem.


For other situations where there's no maven plugin to do what whas done 
in an ant task, there's a maven-antrun-plugin 
(http://maven.apache.org/plugins/maven-antrun-plugin/ ) which allows you 
to run ant task within the maven build process.


Ian Marshall wrote:

Martin Grigorov-4 wrote

Hi Ian,

Thanks for sharing !

May I ask you why you avoid Maven ?
With Maven (and similar dependency management tools) I just change X.Y.Z
to
X.Y.Z+1 in one place and continue working without bothering with all these
steps.

1.  The documentation for Google App Engine for Java (GAE/J) specifies
certain Ant scripts for doing useful things such as application building and
DataNucleus JDO datastore code "enhancement", so I do not want to drop Ant.

2.  I know almost nothing above Maven, except that this seems to be simple
to use with little configuration required to obtain the .jar (and source?)
files needed (and perhaps build an application too?).

3.  I do not know if Maven and Ant are incompatible, although I feel that
they are.

To conclude, I feel that Maven is good and the "modern, sensible way to go",
but for now I'll stick to Ant, in order to avoid the possible requirement to
change all my GAE/J Ant scripts to Maven things.

I'm happy to be told that I am wrong in all this!

I had to change my procedure for Wicket 6 to include the use of Maven.org,
in order to obtain source code files which I could no longer find in the
download mirrors. I shall be happy to update this procedure in the future to
reflect future changes or improvements if you want me to (just let me know
where it resides (if you want to use it)), even though I guess that Maven is
more the future than Ant is.


Ian



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Manual-procedure-to-update-Wicket-for-NetBeans-tp4654064p4654092.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: Manual procedure to update Wicket for NetBeans

2012-11-22 Thread Martin Grigorov
On Thu, Nov 22, 2012 at 3:29 PM, Ian Marshall wrote:

> Martin Grigorov-4 wrote
> > Hi Ian,
> >
> > Thanks for sharing !
> >
> > May I ask you why you avoid Maven ?
> > With Maven (and similar dependency management tools) I just change X.Y.Z
> > to
> > X.Y.Z+1 in one place and continue working without bothering with all
> these
> > steps.
>
> 1.  The documentation for Google App Engine for Java (GAE/J) specifies
>

I see. Google doesn't like Maven.


> certain Ant scripts for doing useful things such as application building
> and
> DataNucleus JDO datastore code "enhancement", so I do not want to drop Ant.
>
> 2.  I know almost nothing above Maven, except that this seems to be simple
> to use with little configuration required to obtain the .jar (and source?)
> files needed (and perhaps build an application too?).
>
> 3.  I do not know if Maven and Ant are incompatible, although I feel that
> they are.
>
> To conclude, I feel that Maven is good and the "modern, sensible way to
> go",
> but for now I'll stick to Ant, in order to avoid the possible requirement
> to
> change all my GAE/J Ant scripts to Maven things.
>
> I'm happy to be told that I am wrong in all this!
>
> I had to change my procedure for Wicket 6 to include the use of Maven.org,
> in order to obtain source code files which I could no longer find in the
> download mirrors. I shall be happy to update this procedure in the future
> to
> reflect future changes or improvements if you want me to (just let me know
> where it resides (if you want to use it)), even though I guess that Maven
> is
> more the future than Ant is.
>
>
> Ian
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Manual-procedure-to-update-Wicket-for-NetBeans-tp4654064p4654092.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
>
>

You can check http://ant.apache.org/ivy/. It adds dependency management to
Ant.

-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com 


Re: Manual procedure to update Wicket for NetBeans

2012-11-22 Thread Ian Marshall
Martin Grigorov-4 wrote
> Hi Ian,
> 
> Thanks for sharing !
> 
> May I ask you why you avoid Maven ?
> With Maven (and similar dependency management tools) I just change X.Y.Z
> to
> X.Y.Z+1 in one place and continue working without bothering with all these
> steps.

1.  The documentation for Google App Engine for Java (GAE/J) specifies
certain Ant scripts for doing useful things such as application building and
DataNucleus JDO datastore code "enhancement", so I do not want to drop Ant.

2.  I know almost nothing above Maven, except that this seems to be simple
to use with little configuration required to obtain the .jar (and source?)
files needed (and perhaps build an application too?).

3.  I do not know if Maven and Ant are incompatible, although I feel that
they are.

To conclude, I feel that Maven is good and the "modern, sensible way to go",
but for now I'll stick to Ant, in order to avoid the possible requirement to
change all my GAE/J Ant scripts to Maven things.

I'm happy to be told that I am wrong in all this!

I had to change my procedure for Wicket 6 to include the use of Maven.org,
in order to obtain source code files which I could no longer find in the
download mirrors. I shall be happy to update this procedure in the future to
reflect future changes or improvements if you want me to (just let me know
where it resides (if you want to use it)), even though I guess that Maven is
more the future than Ant is.


Ian



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Manual-procedure-to-update-Wicket-for-NetBeans-tp4654064p4654092.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: Manual procedure to update Wicket for NetBeans

2012-11-22 Thread Martin Grigorov
Hi Ian,

Thanks for sharing !

May I ask you why you avoid Maven ?
With Maven (and similar dependency management tools) I just change X.Y.Z to
X.Y.Z+1 in one place and continue working without bothering with all these
steps.


On Thu, Nov 22, 2012 at 12:48 PM, Ian Marshall wrote:

> Martin Grigorov-4 wrote
> > Hi,
> >
> > Please paste it here.
> > Isn't it just download the jars from Maven repos or from Apache Dist and
> > put them in your project structure ?
> >
> >
> > On Wed, Nov 21, 2012 at 4:49 PM, Ian Marshall <
>
> > IanMarshall.UK@
>
> > >wrote:
> >
> >> I develop my Wicket application using NetBeans and Ant (not Maven).
> >> ...
> >
> >
> > --
> > Martin Grigorov
> > jWeekend
> > Training, Consulting, Development
> > http://jWeekend.com ;
>
> Almost. I write a procedure to ensure that I do not forget anything.
> Perhaps
> I am over-complicating things and am unaware of a much simpler way to do
> this. Anyway, I copy my procedure below (edited for possible public
> consumption).
>
>
> UPDATING THE WICKET WEB FRAMEWORK WITHIN NETBEANS FOR ANT-BASED PROJECTS –
> PROCEDURE
>
> 
>
> INTRODUCTION
> This procedure assumes that the following Wicket .jar files only are
> needed:
> wicket-core, wicket-request, wicket-util, wicket-devutils. It also assumes
> that slf4j-jdk14 logging is needed by your web application.
>
> Adjust the files to be lownloaded/used if you require a different set of
> files.
>
>
> PROCEDURE
> Visit the Apache Wicket home web site to find out the latest version of
> Wicket (or subscribe to Nabble Wicket announcements and find out that way).
> If a new version of Wicket is to be used for your NetBeans project, then:
> ·  download:
>·  apache-wicket-N.N.N.zip   (for source files)
>·  apache-wicket-N.N.N-bin.zip   (for .jar files)
> ·  visit www.SLF4J.org to check for a new version of the SLF4J .jar files
> used by Wicket and your web application.
>
> If the latest version of Wicket is to be updated, then create a new
> NetBeans
> Wicket Ant library. This will require the creation of a bespoke .zip file.
> As a flexible guide only:
>
>   lib files
>   -
>   Into a folder (such as
> C:\Program Files\Apache Software Foundation\Wicket\NetBeans library\libs)
> copy the files:
>
>   ·  apache-wicket-N.N.N-bin\wicket-core-N.N.N.jar
>   ·  apache-wicket-N.N.N-bin\wicket-request-N.N.N.jar
>   ·  apache-wicket-N.N.N-bin\wicket-util-N.N.N.jar
>   ·  apache-wicket-N.N.N-bin\wicket-devutils-N.N.N.jar
>   ·  slf4j-api-N.N.N.jar and slf4j-jdkNN-N.N.N.jar.
>
>   Under the NetBeans Wicket Ant library Classpath tag go all these new
> files.
>
>
>   src files
>   -
>   Into the bespoke .jar file wicket-N.N.N-sources-NB.jar in a folder (such
> as
>
> C:\Program Files\Apache Software Foundation\Wicket\NetBeans library\sources)
> compress all files in:
>
>   ·  apache-wicket-N.N.N\wicket-core\src\main\java
>   ·  apache-wicket-N.N.N\wicket-request\src\main\java
>   ·  apache-wicket-N.N.N\wicket-util\src\main\java
>   ·  apache-wicket-N.N.N\wicket-devutils\src\main\java.
>
>   Under the NetBeans Wicket Ant library Sources tag goes
> wicket-N.N.N-sources-NB.jar.
>
>
>   apidocs files
>   -
>   Visit http://maven.org and do an advanced search for group ID
> “org.apache.wicket” and version “N.N.N”.
>
>   Download the javadoc.jar files for the artifact IDs:
>
>   ·  wicket-core
>   ·  wicket-request
>   ·  wicket-util
>   ·  wicket-devutils
>
>   of names of the form [Actifact ID]-N.N.N-javadoc.jar.
>
>   Place these files into the a folder (such as
> C:\Program Files\Apache Software Foundation\Wicket\NetBeans library\docs).
>
>
> Adjust the new NetBeans Wicket Ant library to use the files copied/created
> in the 3 folders as set out above.
>
> Create and adjust your NetBeans project’s NetBeans libraries to use the new
> Ant library you have just created (and to stop using the superseded Ant
> library).
>
> If NetBeans cannot find classes whilst compiling, editing an Ant library by
> loading their files and/or folders anew may solve the problem.
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Manual-procedure-to-update-Wicket-for-NetBeans-tp4654064p4654086.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
>
>


-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com 


Re: File download through form submit & feedback messages

2012-11-22 Thread Ernesto Reinaldo Barreiro
Hi,

On Thu, Nov 22, 2012 at 1:12 PM, juhar  wrote:

> Thanks, I already tried that one, and it worked great on other browsers,
> except on IE8 :( With IE8, I would get a pop-up warning about a possibly
> harmful file. I guess IE8 does this with javascript initiated downloads.
> After accepting the file, the download just disappears into thin air.
>
> This has always been a limitation of that approach: it might not work for
some security settings of the browser.


> Large portion of our users are still using IE8, so I was wondering if
> there's a way to do this without ajax. Or some kind of hack for IE8 to make
> the ajax download succeed. Maybe this is more of an IE8 issue after all...
>

Probably the safest thing is to do it in two steps.

1- do form processing
2- if successful show a panel "click here to get the file" with a download
link (where you actually generate the file).

-- 
Regards - Ernesto Reinaldo Barreiro
Antilia Soft
http://antiliasoft.com/ 


Re: File download through form submit & feedback messages

2012-11-22 Thread juhar
Thanks, I already tried that one, and it worked great on other browsers,
except on IE8 :( With IE8, I would get a pop-up warning about a possibly
harmful file. I guess IE8 does this with javascript initiated downloads.
After accepting the file, the download just disappears into thin air. 

Large portion of our users are still using IE8, so I was wondering if
there's a way to do this without ajax. Or some kind of hack for IE8 to make
the ajax download succeed. Maybe this is more of an IE8 issue after all...

-juha



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/File-download-through-form-submit-feedback-messages-tp4654087p4654089.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: File download through form submit & feedback messages

2012-11-22 Thread Bas Gooren

Hi,

Have a look at 
https://cwiki.apache.org/WICKET/ajax-update-and-file-download-in-one-blow.html 
and try to make it work in wicket 6 (should be easy).


This allows you to do ajax updates (e.g. refresh the form) and then 
redirect the browser to the file.


Met vriendelijke groet,
Kind regards,

Bas Gooren

Op 22-11-2012 12:51, schreef juhar:

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.

I tried submitting the form with ajax using AjaxButton, and was able to
clear the feedback messages, but unfortunately it would not work on IE8...
IE8 will warn you about the file with a pop-up, and after that the download
will just disappear. Also any of my attempts to manually clear the feedback
messages have failed.

What would be correct way of creating this? I'm using Wicket6. This is the
code I'm using currently (relevant bits only):

// In the Panel-constructor
form.add(new Button("createreportbutton") {
 @Override
 public void onSubmit() {
 createReport();
 }
});

// Generates the report, and response
private void createReport() {
 // Generate report with something like:
 reportCommand.generateReport(formValues);
 final byte[] reportData  = reportCommand.getReportData();
 final String contentType = reportCommand.getContentType();
 final String contentDisposition = reportCommand.getContentDisposition();

 // Give the report as download
 getRequestCycle().scheduleRequestHandlerAfterCurrent( new
IRequestHandler() {
 @Override
 public void detach(IRequestCycle reqCycle) {
 }

 @Override
 public void respond(IRequestCycle reqCycle) {
 WebResponse response = (WebResponse)reqCycle.getResponse();
 HttpServletResponse res =
(HttpServletResponse)response.getContainerResponse();
 res.setContentType(contentType);
 res.setHeader("Content-Disposition", contentDisposition);
 try {
 res.getOutputStream().write(reportData);
 } catch (IOException ex) {
 ApplicationLogger.error("Error writing report to HTTP
response", ex);
 }

 }
 });
}

Thanks,
Juha



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/File-download-through-form-submit-feedback-messages-tp4654087.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





File download through form submit & feedback messages

2012-11-22 Thread juhar
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.

I tried submitting the form with ajax using AjaxButton, and was able to
clear the feedback messages, but unfortunately it would not work on IE8...
IE8 will warn you about the file with a pop-up, and after that the download
will just disappear. Also any of my attempts to manually clear the feedback
messages have failed.

What would be correct way of creating this? I'm using Wicket6. This is the
code I'm using currently (relevant bits only):

// In the Panel-constructor
form.add(new Button("createreportbutton") {
@Override
public void onSubmit() {
createReport();
}
});

// Generates the report, and response
private void createReport() {
// Generate report with something like:
reportCommand.generateReport(formValues);
final byte[] reportData  = reportCommand.getReportData();
final String contentType = reportCommand.getContentType();
final String contentDisposition = reportCommand.getContentDisposition();

// Give the report as download
getRequestCycle().scheduleRequestHandlerAfterCurrent( new
IRequestHandler() {
@Override
public void detach(IRequestCycle reqCycle) {
}

@Override
public void respond(IRequestCycle reqCycle) {
WebResponse response = (WebResponse)reqCycle.getResponse();
HttpServletResponse res =
(HttpServletResponse)response.getContainerResponse();
res.setContentType(contentType);
res.setHeader("Content-Disposition", contentDisposition);
try {
res.getOutputStream().write(reportData);
} catch (IOException ex) {
ApplicationLogger.error("Error writing report to HTTP
response", ex);
}

}
});
}

Thanks,
Juha



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/File-download-through-form-submit-feedback-messages-tp4654087.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: Manual procedure to update Wicket for NetBeans

2012-11-22 Thread Ian Marshall
Martin Grigorov-4 wrote
> Hi,
> 
> Please paste it here.
> Isn't it just download the jars from Maven repos or from Apache Dist and
> put them in your project structure ?
> 
> 
> On Wed, Nov 21, 2012 at 4:49 PM, Ian Marshall <

> IanMarshall.UK@

> >wrote:
> 
>> I develop my Wicket application using NetBeans and Ant (not Maven).
>> ...
> 
> 
> -- 
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com ;

Almost. I write a procedure to ensure that I do not forget anything. Perhaps
I am over-complicating things and am unaware of a much simpler way to do
this. Anyway, I copy my procedure below (edited for possible public
consumption).


UPDATING THE WICKET WEB FRAMEWORK WITHIN NETBEANS FOR ANT-BASED PROJECTS –
PROCEDURE


INTRODUCTION
This procedure assumes that the following Wicket .jar files only are needed:
wicket-core, wicket-request, wicket-util, wicket-devutils. It also assumes
that slf4j-jdk14 logging is needed by your web application.

Adjust the files to be lownloaded/used if you require a different set of
files.


PROCEDURE
Visit the Apache Wicket home web site to find out the latest version of
Wicket (or subscribe to Nabble Wicket announcements and find out that way).
If a new version of Wicket is to be used for your NetBeans project, then:
·  download:
   ·  apache-wicket-N.N.N.zip   (for source files)
   ·  apache-wicket-N.N.N-bin.zip   (for .jar files)
·  visit www.SLF4J.org to check for a new version of the SLF4J .jar files
used by Wicket and your web application.

If the latest version of Wicket is to be updated, then create a new NetBeans
Wicket Ant library. This will require the creation of a bespoke .zip file.
As a flexible guide only:

  lib files
  -
  Into a folder (such as
C:\Program Files\Apache Software Foundation\Wicket\NetBeans library\libs)
copy the files:

  ·  apache-wicket-N.N.N-bin\wicket-core-N.N.N.jar
  ·  apache-wicket-N.N.N-bin\wicket-request-N.N.N.jar
  ·  apache-wicket-N.N.N-bin\wicket-util-N.N.N.jar
  ·  apache-wicket-N.N.N-bin\wicket-devutils-N.N.N.jar
  ·  slf4j-api-N.N.N.jar and slf4j-jdkNN-N.N.N.jar.

  Under the NetBeans Wicket Ant library Classpath tag go all these new
files.

  
  src files
  -
  Into the bespoke .jar file wicket-N.N.N-sources-NB.jar in a folder (such
as
C:\Program Files\Apache Software Foundation\Wicket\NetBeans library\sources)
compress all files in:

  ·  apache-wicket-N.N.N\wicket-core\src\main\java
  ·  apache-wicket-N.N.N\wicket-request\src\main\java
  ·  apache-wicket-N.N.N\wicket-util\src\main\java
  ·  apache-wicket-N.N.N\wicket-devutils\src\main\java.
  
  Under the NetBeans Wicket Ant library Sources tag goes
wicket-N.N.N-sources-NB.jar.


  apidocs files
  -
  Visit http://maven.org and do an advanced search for group ID
“org.apache.wicket” and version “N.N.N”.

  Download the javadoc.jar files for the artifact IDs:

  ·  wicket-core
  ·  wicket-request
  ·  wicket-util
  ·  wicket-devutils

  of names of the form [Actifact ID]-N.N.N-javadoc.jar.

  Place these files into the a folder (such as
C:\Program Files\Apache Software Foundation\Wicket\NetBeans library\docs).


Adjust the new NetBeans Wicket Ant library to use the files copied/created
in the 3 folders as set out above.

Create and adjust your NetBeans project’s NetBeans libraries to use the new
Ant library you have just created (and to stop using the superseded Ant
library).

If NetBeans cannot find classes whilst compiling, editing an Ant library by
loading their files and/or folders anew may solve the problem.



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Manual-procedure-to-update-Wicket-for-NetBeans-tp4654064p4654086.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: How important is detaching models really ?

2012-11-22 Thread Martin Grigorov
Hi,

Check https://cwiki.apache.org/confluence/display/WICKET/Page+Storage
Only the last used page is stored temporarily in the http session.
Detaching the models decreases the used memory.


On Thu, Nov 22, 2012 at 12:09 PM, tobi wrote:

> Hi guys,
>
> From my understanding & experiments with Wicket's built-in session
> inspector , detaching models seems to just affect the size of the page
> store (and of course cut-down the amount of I/O required for serializing
> the object graph). The session size shown on my pages is a constantly low
> value (<1k , we're storing nothing except the currently logged-in user).
>
> So it *seems* not detaching models has no effect on the (long-term) memory
> footprint of a Wicket application.
>
> According to https://cwiki.apache.org/**WICKET/working-with-wicket-**
> models.html, 
> not detaching models should affect the session size but at least looking
> at the inspector I can't see this. Is the wiki article still correct / the
> inspector not telling the truth ?
>
> Thanks,
> Tobias
>
> P.S. I'm using Wicket 1.5.8 btw
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@wicket.**apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com 


Re: Handling of Ajax response fails [Fragments]

2012-11-22 Thread Gonzalo Aguilar Delgado
Hello, 

I will trace the Wicket.Head.Contributor.processScript to see what's
missing. It seems dojo libraries are not loaded at this point, even if
the script section that loads it is there. 

Any directions on how to trace this problem? I'm a little bit lost...

Thank you.
Kindest regards


El mar, 20-11-2012 a las 10:31 +0100, Gonzalo Aguilar Delgado escribió:

> Hello, 
> 
> I'm doing a scaffolding application for wicket + dojo. I'm using
> fragments to change between EDIT, UPDATE, DELETE screens. 
> 
> On each switch I have to reinitializate components on the changed zone
> of the web via javascript. I've implemented this in a clean
> and efficient way ( I think ), because code generated is really concise
> and tested.
> 
> The problem is that it works for 2 iterations. On the thirth it breaks
> with an ajax DEBUG error.
> 
> -
> /*]^]^>*/
> 
> 
> ]]>
> ERROR: Wicket.Head.Contributor.processScript: TypeError: a is undefined: eval 
> -> 
> require(["dijit/MenuBar","dijit/registry","dojo/parser","dojo/ready","dijit/MenuBarItem","dojo/on"],function(MenuBar,
>  registry, parser, ready, MenuBarItem, on) {
> // Component section begins
> // Ready Dojo statement
> ready(function() {
> // Added class dijit/MenuBar
> parser.parse(registry.byId("toolbar29"));
> // Added class dijit/MenuBarItem
> parser.parse(registry.byId("id12a"));
> on(registry.byId("id12a"), 'click',function(event) {
> if (true) 
> {Wicket.Ajax.ajax({"u":"./?13-2.IBehaviorListener.2-scaffold-wscaffold~content-toolbar-dijitMenuBarItems-1","c":"id12a"});}
> });
> // Added class dijit/MenuBar
> parser.parse(registry.byId("toolbar2b"));
> 
> });
> });
> INFO: Response processed successfully.
> INFO: refocus last focused component not needed/allowed
> INFO: focus set on wicketDebugLink
> INFO: focus removed from wicketDebugLink
> 
> 
> -
> 
> It weird because if I run this on firefox just after it breaks, It
> works! And the code is similar on the three events I trigger on the 
> tests.
> 
> 
> What I do in the interface:
> 
> START POINT -> TRANSITION 1 -> START POINT (It breaks)
> 
> I was reading about this kind of problems but the only problem I can
> find is that some components does not get destroyed. But this should be
> not a problem
> just right now because I create new components with new names in each
> iteration. (Okay I know about the memory leaks, but's not the point just
> right now).
> 
> 
> Any help on this?
> 
> --
> 
> I pasted complete log in pastie.org
> 
> http://pastie.org/5405231
> 
> 
> Thank you in advance!
> 
> 
> 


Re: SV: applet in wicket .. exception thrown ...

2012-11-22 Thread venkat
Hi,

Am in similar situation, where i have an applet which takes two parameters
and in my wicket web page thereis a link when user clicks on that link i
need to display this applet. could you please share how you have created the
applet object and passed the parameters and displayed the applet. 
I woulod really appreciate , if you can share the code for html and java
class as well.

Thanks in advance!!



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/applet-in-wicket-exception-thrown-tp1845048p4654083.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



How important is detaching models really ?

2012-11-22 Thread tobi

Hi guys,

From my understanding & experiments with Wicket's built-in session 
inspector , detaching models seems to just affect the size of the page 
store (and of course cut-down the amount of I/O required for serializing 
the object graph). The session size shown on my pages is a constantly 
low value (<1k , we're storing nothing except the currently logged-in user).


So it *seems* not detaching models has no effect on the (long-term) 
memory footprint of a Wicket application.


According to 
https://cwiki.apache.org/WICKET/working-with-wicket-models.html , not 
detaching models should affect the session size but at least looking at 
the inspector I can't see this. Is the wiki article still correct / the 
inspector not telling the truth ?


Thanks,
Tobias

P.S. I'm using Wicket 1.5.8 btw

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: adding swing Jframe inside Wicket webpage

2012-11-22 Thread Marc Nuri San Félix
Hi
I believe there are two solutions for your question:

   1. You could do this with an Applet, and place it in a Page.
   2. One other solution could be to set the content type of the JTextPane
   to "text/html", get the content with getText() and display it using a
   WebMarkupContainer or similar Component.

I think you should reconsider the libary you are using to compare the
documents, or see what the library is doing so that you can avoid the use
of the JTextPane.

Cheers
--
Marc Nuri
www.marcnuri.com


On Thu, Nov 22, 2012 at 10:53 AM, Andrea Del Bene wrote:

> No, there's no way to get what you are asking for.
>
>> Hi ,
>>
>> In my application, am using one open source tool to compare xml documents,
>> this tool returns JtextPanes as a result , right now am putting these text
>> panes in a Jframe and displaying Jframe. Now i want to show this Jframe
>> inside wicket response page. is there any way I can put swing compoent
>> inside any wicket container and set reponse page as this.
>>
>>
>> I would appreciate quick response.
>>
>>
>>
>> --
>> View this message in context: http://apache-wicket.1842946.**
>> n4.nabble.com/adding-swing-**Jframe-inside-Wicket-webpage-**
>> tp4654079.html
>> Sent from the Users forum mailing list archive at Nabble.com.
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> users-unsubscribe@wicket.**apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@wicket.**apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: adding swing Jframe inside Wicket webpage

2012-11-22 Thread Andrea Del Bene

No, there's no way to get what you are asking for.

Hi ,

In my application, am using one open source tool to compare xml documents,
this tool returns JtextPanes as a result , right now am putting these text
panes in a Jframe and displaying Jframe. Now i want to show this Jframe
inside wicket response page. is there any way I can put swing compoent
inside any wicket container and set reponse page as this.


I would appreciate quick response.



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/adding-swing-Jframe-inside-Wicket-webpage-tp4654079.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