Hi Eelco,
I saw you mention Hibernate in the intro but I've been using JPOX with
great success with Wicket also. You might want to mention that in the
book or new comers might think Wicket is a Hibernate only framework.
I use JPOX through the open source exPOJO (shameless plug!
www.expojo.com)
these days.
We've worked with a Boston company before back in 2000. These days of
Skype and video conferencing would make that even easier and less
expensive.
Regards,
Chris Colman
Technical Directory
http://stepaheadsoftware.com
I have a number of pages that display a list of items and am wondering
about the best approach to implementing them in Wicket.
To date I have created a single panel that contains the list and the
markup for that panel holds the discrete markup elements for the fields
in each item of the list.
Well here's our story, if it helps you.
Here's ours as well:
Wicket (+some Echo2) + exposed POJO model managed by Javelin + JPOX
for the ORM.
Having come from a JSP/Struts + home grown ORMish kind of framework
using proxy/reflection implementation (yuck) this new set of tools is
***ken awesome
I have content that I render that may or may not have a URL associated
with it. I don't want to display anything if the URL is blank.
I use ExternalLink for the URLs. As I place a reference to the link in
my markup I need to instantiate an ExternalLink object in the
corresponding page/panel
a http:// in front of it making a trivial test not
possible.
-igor
On 10/2/07, Chris Colman [EMAIL PROTECTED] wrote:
I have content that I render that may or may not have a URL
associated
with it. I don't want to display anything if the URL is blank.
I use ExternalLink for the URLs
]
Sent: Wednesday, 3 October 2007 4:36 PM
To: users@wicket.apache.org
Subject: Re: Making ExternalLink invisible: test for what?
why not use the setVisible method?
link.setVisible(StringUtils.isNotBlank(url)
StringUtils.isNotBlank(...));
Martijn
On 10/3/07, Chris Colman [EMAIL PROTECTED
To date we've built all of our static pages in Wicket and all dynamic
pages/user input forms etc., in Echo because it provides a pure Java (no
need to write any JavaScript) solution to generating AJAX powered pages.
The problem is when users switch from Echo pages back to Wicket pages
using the
I've created a form and set up some validators on various fields. When
there is an error and the page is redisplayed showing the errors none of
the previous values that the user typed in are there.
Is there an easy way to preserve the values already entered by the user?
I tried overriding
wicket.markup.html.image.*;
import wicket.extensions.markup.html.captcha.*;
import java.lang.*;
import java.util.Random;
// -[Class]-
/**
* Information Request Page.
*
* @author Chris Colman
*/
public
class InformationRequestPage extends StandardPage
{
// -[KeepWithinClass]-
// inner class
Oh yeah, I'm using Wicket 1.2.6 if that has any bearing on the
situation.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
the form component is added in mark up inside a
wicket:extend
... form sits in here ...
/wicket:extend
construct.
On 11/1/07, Chris Colman [EMAIL PROTECTED] wrote:
Oh yeah, I'm using Wicket 1.2.6 if that has any bearing on the
situation
can you make sure your servlet mapping is of form /foo/*
-igor
Yes it's of that form.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I found an excellent thread in the archives that explains this topic
very
well - I swear I searched before, but obviously with the wrong
keywords ;)
http://www.nabble.com/Multiple-wicket%3Achild-tags-in-the-same-page-tf37
75143.html
Multiple child/extends pairs (where you have to see such a
components don't preserve their values.
try it without that funky onerror() override.
I commented out the funky onerror() override and the problem still
exists.
H, getting curiouser and curiouser!
-igor
On 11/2/07, Chris Colman [EMAIL PROTECTED] wrote:
can you make sure your servlet
It would be quite feasible to add support for multiple overridden
sections using the above tag names while remaining backwards
compatible
with existing markup by continuing to support the old
child/extends
tags working the way they always have.
It's kind of a predictable answer, but the
There's nothing I would love more right now than to have to time to
implement a patch to support multiple overridden sections in a
wicket
page but unfortunately time is one thing I don't seem to have much
of
these days. I can't believe 2007 is almost over - heck, where did
this
year go?
Could it be because the form page is bookmarkable?
thats odd, all the values should be preserved, thats our rawinput that
all formcomponents have. Do you have a repeater/listview around your
formcomponents.
On 11/1/07, Chris Colman [EMAIL PROTECTED] wrote:
I've created a form and set up
Ok, I'll do that. The problem probably won't happen in the quickstart
form ;)
why dont you submit a quickstart and then we can figure out why its
happening
-igor
On 11/2/07, Chris Colman [EMAIL PROTECTED] wrote:
Could it be because the form page is bookmarkable?
thats odd, all
Is there a page with guidelines on making a wicket quickstart?
why dont you submit a quickstart and then we can figure out why its
happening
-igor
On 11/2/07, Chris Colman [EMAIL PROTECTED] wrote:
Could it be because the form page is bookmarkable?
thats odd, all the values should
I was wondering if anyone has started a Wicket project (instead of the
JSF
endorsed one). I would hate to recreate the wheel if someone has
already
started a similar project.
Come on! Recreating the wheel is what us software engineers do best!
Imagine how boring the wheel would be if we hadn't
if i were you i would use tags other then extend and child just so you
dont conflict.
Yes Stefan, I would think that would be a better approach to use a new set of
tags. It also allows you to choose more correct naming (because inheritance
isn't actually a parent/child relationship so the
the complement to abstract is implement not override... names are
important.
Arh, sorry, I made my last post before reading yours Igor. Yes, I agree
abstract/implement make a great complimentary pair.
-
To unsubscribe,
Wouldn't this essentially be the same as using wicket:panel
id=header/ and using WebMarkupContainers on the java side?
I.e.:
Base
Structural markup goes here (see below for explanation of this)
wicket:panel id=header /
More structural markup goes here
wicket:panel id=body /
And
is then just an ordinary case of multiple where
n=1.
However, I'll consider using a different name and separate implementation
for the prototype.
-- Stefan
Chris Colman wrote:
if i were you i would use tags other then extend and child just so you
dont conflict.
Yes Stefan, I
Wouldn't this essentially be the same as using wicket:panel
id=header/ and using WebMarkupContainers on the java side?
yes it would be exactly the same thing.
If you think that these are the same then you've missed some vital plot
points of the movie that it child/extend.
Hmmm... more tags? I thought you guys liked Wicket because it's plain
html
support. Now looks like there's a big interest in having more tags. If
this is true, why don't we go back a few years, or move to JSF? Let's
give
Wicket support to Tag Libraries too :)
These aren't just like other
I'll do that again
in a following post.
Chris Colman wrote:
Wouldn't this essentially be the same as using wicket:panel
id=header/ and using WebMarkupContainers on the java side?
I.e.:
Base
Structural markup goes here (see below for explanation of this)
wicket:panel
Given these subtle problems with this approach, I admit I'm warming
to
the multiple extend/child idea.
im oposite - if i have X extends in a page, whose extend should be
preferred (e.g: manipulating the head or a part outside of itself) ?
I'm not sure I understand the issue you raise
And if somebody really needs 5 child areas, something else might be
even
messier than the page's constructor. I rather think that 2, 3 or in
rare
cases even 4 ids could make sense.
i must disagree - i have a basepage which defines the default layout
on a
project, i.e. header,
How can it get messy when it's not yet possible to do in wicket?
i believe it has been shown multiple times already that it CAN be done
with vanilla wicket...
I didn't like the look of any of those 'coded' solutions. They were not
from the coding elegance book I've read. They also mean I'm
a lot of people are saying that this can be implemented with panels,
and that is true. but actually implementing this with fragments will
make it look very similar to this new strategy and does not have the
id collission problem, because components ARE nested in two different
containers:
Presumably the coded work arounds that don't rely on child/extends mean
that the structural markup of each page is used instead of just that of
the base page - and that would spell maintenance issues. Without using
child/extend then ALL the structural markup in each page is used for
each render -
Korbinian Bachl wrote:
you missed solution3:
the real-wicket-way(tm) for multiple content-places in a tied
page-area:
Whaaa, I seriously hope this is not the real-wicket-way! My brain
hurts!
A framework is supposed to make things easy and readable! The code
below
is just way too
and in extending classes you can easily do this:
protected void initialize() {
addToAnything(new AnyPanel(id));
addToAnything(new AnyPanel2(id2));
}
So now you're proposing the Java code is defining the layout of
components? That's what the markup's job is I
ok tell me with 2 examples what is soo different about having 2 panels
(or
fragments)
in a page and implement that in a sub page or having 2 wicket childs
in a
page and implement those in a sub page.
Ok, here we go... (well one example at least - it's getting late here ;)
)
I'm not sure
...
5) Conclusion
In conclusion, the proposed change:
- is useful
- does not have to be used if you don't like it
- is 100% backwards compatible
- it introduces no new tags (if using child/extends)
I also do not see any real issues. This is purely about merging
The advantage of having this separate project
is that such inheritance would be available for people who like it,
and hey, maybe in the longer term you have something that works so
good that you can convince people based on something that works.
Executable code works much better than
heh, wellyou can be against this, but i think if we take a vote
right now most core-devs with binding votes will vote this down
I still can't see the reason for the negativity of some of the
core-devs: this is an existing feature.
If the feature sucks so bad why did people have the
That is what I'd suggest as well, since it involves the least amount
of
change. As an added bonus, if no id's are added and 2 wicket:child
sections are used, it could throw an exception (which it currently
does
not do, it just silently ignores the second wicket:child).
That would be magic!
Hi,
Actually, Wicket already works like this. It does *NOT* require the
wicket:extend, and if it's not present it just renders the contents
of
the wicket:child. (Just tested this with beta4).
Awesome!
[This behaviour must have changed since 1.2.6 because I tried removing
the extend tag in a
i plan to use JPA together with Wicket. Are there any
battle-proven
best-practices out there of how to handle EnityManagers and
Transactions?
What do other people use (no, not the spring crowd ;) ?
One EntityManager per Request seems to be the obvious idea and a
guice
I give up. Looks like this enhancement is really receiving positive
votes.
:)
:) :) :) :) :) :) :) :)
Just some of the many happy faces!
In my second reason, I point to something that is... the _core_ of
wicket:
binding Java objects (Components) to HTML tags. So, not having this
I'm using the wicket extensions CAPTCHA feature which works perfectly
except:
I know the purpose of CAPTCHA is to make the text unreadable to a
certain extent but it's *TOO* good at making the text unreadable - such
that humans often get it wrong too.
I have a client who has complained that
i hope you guys realize that this isnt a wicket issue, its an issue
with the captcha lib that wicket uses - thats what is generating the
image.
I realized that it was a third party thing. If it was written by the
wicket devs it would rock like everything else they write!
so why not simply
The trouble is that the answers to the kitten questions usually have a
small number of possible combinations: 1 - 5 roughly so on average a
robot may be successful 20% of the time.
thoof.com has a better captcha: select the kittens. I'd love to know
if it works for them or not.
Martijn
Chris Colman schrieb:
The obvious benefit in such an approach is that your POJO model and the
services that you provide to implement business rules etc., remain
completely portable to different persistence engines - ie., no vendor
lock in.
well, i thought that was JPA was all about
Evan Chooly wrote:
Do you know if theres any plans on making a maven2 archetype for
qwicket?
That's a definite feature i plan on adding as soon as I can. As a
noted maven hater, though, it'll take some time and libations to
help
me swallow my pride. :)
Good luck! Archetypes
Chris Colman wrote:
It seems it's also possible for a few other ORM tools to conform to
that
standard. Apart from Hibernate and JPOX you've got TopLink, Cayenne
and
others.
That's my point.
Which would you rather depend on; exPOJO or JPA?
Two different things:
exPOJO is a lightweight
Hello
I've browsed over the wicket documentation and examples. There are a
couple of things I don't seem able to determine. So I would really
appreciate your input on this questions.
1. Can I write a web application without coding any HTML
whatsoever?...
I mean, is there some kind of html
I have a client who employs a professional SEO guy. He's told the client
that my use of /productId/3 (as per the wicket standard) is not kosher
with the search engines and that I should be using the traditional
?product=3 query stuff as the search engines produce better rankings for
pages with
I'm having trouble with borders as well.
This markup is within a page and I use a component resolver and in the
debug I see requests for the 'primaryWrapper' (PrimaryWrapper is a class
derived from Border. I then see the resolve request to resolve
'aboutUsPanel'. The panel is created and added to
once had to code for an entire month,
barefoot, in the dead of winter, using just 0's... but you didn't hear
me complaining.
-Original Message-
From: Chris Colman [mailto:chr...@stepaheadsoftware.com]
Sent: Friday, 4 September 2009 11:05 AM
To: users@wicket.apache.org
Subject: RE
I apologize in advance if there is a completely obvious solution to this
that I have missed...
Is it possible to pass in parameters to a panel via the markup?
Eg., Let's say that there are number of different ways that a particular
panel could be rendered and that these ways are largely
- where you have access
to
data sources, session attributes, the user, etc
--
Jeremy Thomerson
http://www.wickettraining.com
On Mon, Sep 7, 2009 at 5:09 PM, Chris Colman
chr...@stepaheadsoftware.comwrote:
I apologize in advance if there is a completely obvious solution
you say it is laughable to require knowledge of code to configure
this. i agree, but i also think its laughable to require the knowledge
of markup, why shouldnt a sysadmin be able to change this? so isnt a
property file, or a jndi property, or a database table a better place
to configure
Then why not just create a configuration panel so your designer can
configure the number of items to display?
Scenario:
Let's say 8 different pages use the same SongChartPanel and each wants
to list a different number of songs.
Providing a configuration panel for the web designer to configure
officially we will not support this type of control because there are
plenty of other alternatives which we find more appealing. that said,
there are plenty of ways for you to accomplish what you want, we do
not slam doors on ideas just because we dont agree with them.
eg you can use
Thomerson
http://www.wickettraining.com
On Mon, Sep 7, 2009 at 9:47 PM, Chris Colman
chr...@stepaheadsoftware.comwrote:
officially we will not support this type of control because there
are
plenty of other alternatives which we find more appealing. that
said,
there are plenty of ways
I'm doing some experimenting with ComponentTag.getAttributes() - it
looks
like the one!!
Doh! It doesn't seem to work. No matter how many attributes I add to the
tag and no matter whether I add the wicket: namespace to them or not I
only ever see the single wicket:id attribute when I run this
-Original Message-
Doh! It doesn't seem to work.
...
Whoops! Please ignore the above!
It works like a charm when you place the parameters in the right place
;)
-
To unsubscribe, e-mail:
eg you can use IComponentResolver and create a factory panel that can
create a child based on the attributes of a tag, etc.
-igor
Well it worked well to a point. That point was when I tried to place two
panels of the same type but with different attributes on the same page.
The second panel
Chris Colman wrote:
I've thought of a very ugly way of doing it with the current version
of
wicket but it relies on quite a lot of smoke and mirrors and hooking
into the component creation process. I'll give that a go for now.
We went a similar but still different way :) We use our own
why? what is different between a 10 or a 50 item song panel? the
number
of items? you should anyhow use a ListView which repeats the her is
the
song-block as many times as you want to..
It is using a ListView - the desire was to provide an easy way for the
UI guy to specify a row count in the
With using the getVariation() method is the 'fallback' process for when
a particular variant isn't found like this:
(a) Incremental removal of variant suffixes using '_' as the delimeter:
i.e. Wicket looks for files in the following order until one is found:
HeaderPanel_Var1_Var2_Var3.html
Subject: RE: Passing parameters from markup to panels
Am Donnerstag, den 10.09.2009, 14:03 +1000 schrieb Chris Colman:
why? what is different between a 10 or a 50 item song panel? the
number
of items? you should anyhow use a ListView which repeats the her
is
the
song-block as many times
in the
return value of getVariation().
-igor
On Thu, Sep 10, 2009 at 1:21 AM, Chris Colman
chr...@stepaheadsoftware.com wrote:
With using the getVariation() method is the 'fallback' process for
when
a particular variant isn't found like this:
(a) Incremental removal of variant suffixes using
I have a need to 'wrap' some content inside some border style markup,
specifically within a li ... /li combo but the panel that is being
inserted may be visible or invisible depending on logic within the panel
and the current session etc,.
When the 'wrapped' panel is invisible I don't want the li
If they don't, what would be the best way to have the border go
invisible if the child is invisible?
How about using wicket:enclosure child=wrappedPanel around the
border.
refer
http://cwiki.apache.org/WICKET/wickets-xhtml-
tags.html#Wicket%27sXHTMLtags-Elementwicket:enclosure
On Thu, Sep 17, 2009 at 2:19 PM, Chris Colman
chr...@stepaheadsoftware.comwrote:
If they don't, what would be the best way to have the border go
invisible if the child is invisible?
How about using wicket:enclosure child=wrappedPanel around the
border.
I'm using my own
Is it possible to create a panel that's inside a wicket:enclosure vi
an IComponentResolver implementation.
If so where do I hook into such a beasty?
I've tried replacing the standard EnclosureResolver in the apps
collection of resolvers with a CustomEnclosureResolver than I created by
extending
Do you consider to use jsp for this project? They do the entire
servlet
based on the tag name.(just kidding)
I've done my time in the jsp concentration camp - no more please! =)
Make sure of remove the old standard EnclosureResolver and add your
new
one on:
Yes, I've done that. I've made my
From the stack trace you can see that the EnclosureResolver calls
autoAdd which proceeds to do a render and eventually call
getChildComponent - which obviously fails.
It would seem like there needs to be some call to a resolver invoked for
the newly created Enclosure object itself to give it a
I suppose one way around it would be to override Enclosure and create a
DynamicEnclosure that supports the child components being resolved
dynamically by a resolver. I then make my CustomEnclosureResolver return
a DynamicEnclosure instead of a standard Enclosure.
I guess to do that I'd need to
As can be seen by the Enclosure.getChildComponent method below the
component resolver expects to find the 'child' within its own parent -
i.e. it assumes that its *child* is actually its sibling via:
child = parent.get(childId.toString());
While all other children of the common parent are
a collection of them in the settings so does this need to be iterated
through until one returns 'true' or is there somewhere in the framework where
this iterating code can be called?
Regards,
Chris
On Thu, Sep 17, 2009 at 1:57 PM, Chris Colman
chr...@stepaheadsoftware.com wrote:
As can be seen
ComponentResolvers.resolve(MarkupContainer parent, )
hope this gets you started.
-igor
Regards,
Chris
On Thu, Sep 17, 2009 at 1:57 PM, Chris Colman
chr...@stepaheadsoftware.com wrote:
As can be seen by the Enclosure.getChildComponent method below the
component resolver expects to find
to make the component a direct child of enclosure you would have to
have an Enclosure component that is explicitly added into the
hierarchy, at which point you can simply use a WebMarkupContainer
whose visibility is tied to that of the child to replicate the
functionality. the whole point of
that it was an Enclosure but now that you explain it
as a two phase process:
1) handle tag to get a wicket:id
2) resolve the enclosure component i.e. look for a component with that
wicket:id
it now makes sense.
-igor
On Fri, Sep 18, 2009 at 8:35 PM, Chris Colman
chr...@stepaheadsoftware.com wrote
this contract is not factored out anywhere, but maybe doing so may
be
worthwhile. can be part of your patch, something like
ComponentResolvers.resolve(MarkupContainer parent, )
Yes looks like this code in MarkupContainer.renderNext would need to be
factored out:
// 3rd try: Try
this contract is not factored out anywhere, but maybe doing so
may
be
worthwhile. can be part of your patch, something like
ComponentResolvers.resolve(MarkupContainer parent, )
I've tried invoking the application resolvers from many different places
within the Enclosure class but
as far as i rememember there is a collection registered in
setttings
and then each component can also implement a resolver.
the contract can be seen in markupcontainer#rendernext method
1) first walk over the component hierarchy and check if any are
resolvers
2) walk over collection
as far as i rememember there is a collection registered in
setttings
and then each component can also implement a resolver.
the contract can be seen in markupcontainer#rendernext method
1) first walk over the component hierarchy and check if any are
resolvers
2) walk over
I've been using wicket under for a while now, always using ant, but now
I have to create a quickstart app and I'm new to maven...
I've created the quickstart app and it runs under Jetty no problem but
where does it store the Wicket and Jetty .jars?
They don't seem to be under the directory I
for a main build server allowing all logged-in
users
to build from a common local repository.
On Wed, Sep 23, 2009 at 11:01 PM, Chris Colman
chr...@stepaheadsoftware.com
wrote:
I've been using wicket under for a while now, always using ant, but
now
I have to create a quickstart app and I'm
Also, because we run in very large clusters, redirects
are out of the question due to the potential that the second request
hits
a different server before HTTP session has been properly
persisted/shared.
Can't you set up server affinity for the cluster to avoid that from
occurring?
With version 1.4.2 I finally got a component resolver mechanism working
for components within enclosures so that the components could be
dynamically populated instead of hard coding the creation of every
possible component that 'might' be needed by the markup.
I just upgraded to 1.4.5 and my
With version 1.4.2 I finally got a component resolver mechanism working for
components within enclosures so that the components could be dynamically
populated instead of hard coding the creation of every possible component that
'might' be needed by the markup.
I just upgraded to 1.4.5 and my
I know JSF is standard; what is your idea about current JSF
status?
Just forget about it ... ;)
Agreed!
JSF is way too complex for doing simple things. They -again- forgot
the
KISS principle (Keep it Simple Straightforward/Stupid).
Wicket (but also Tapestry) is in my opinion a giant
It seems like 1.4.4 will throw the error, as you say
for *any* missing child declared inside enclosure's markup
but unfortunately it appears to throw it even if the child is available
by a component resolver.
Version 1.4.2 does not throw an error if the child is found via the
component resolver
Currently in our wicket app we have multiple pages and panels that can
pop up ModalWindows depending on user actions. To support this we have
tags like like:
div wicket:id=someModalWindow/div
Sprinkled through various markups.
All of our pages derive from a single page class and I was wondering
I suppose the pop up/ModalWindow Nirvana that I'm seeking would be to
have modals handled as easily as they are in deskop apps:
Create a class derived from ModalWindow
Instantiate it and call showModal.
Without having to worry about adding tags to every page or panel markup
that may require a
We have a site with lots of wicket AJAX working fine but we needed to
add a
base href=http://www.mysite.com/; /
because the site uses a Rich Text editor that wants to convert all
absolute links to links relative to www.mysite.com/
Adding this base tag seems to have broken all AJAX on the site
Another extremely light weight IoC with ORM wrapping (JDO and Hibernate)
is exPOJO at http://www.expojo.com
No need for old fashioned DAOs etc., just POJOs being persisted
transparently the way they should be.
In terms of serialization:
Is that for the purpose of scaling in a cluster
serialized as well?
-Original Message-
serialization in the context when you need to serialize the object -
eg wicket serializes its pages for offline storage, etc.
-igor
On Thu, May 28, 2009 at 5:51 PM, Chris Colman
chr...@stepaheadsoftware.com wrote:
Another extremely light weight IoC
then that you can use a loadabledetachablemodel to release the
reference when the page is not used.
-igor
On Thu, May 28, 2009 at 6:40 PM, Chris Colman
chr...@stepaheadsoftware.com wrote:
Is that controllable?
What if I have complex object models referenced from wicket UI
components that I
expiration.
-igor
On Thu, May 28, 2009 at 6:54 PM, Chris Colman
chr...@stepaheadsoftware.com wrote:
When you say offline storage do you mean that the user has chosen
to
save pages for future offline reference or do you mean a more
'automated' process that wicket performs when system memory
by default. if you use
httpsessionstore the problem will only appear when clustering or when
servlet container spools sessions to disk.
-igor
On Thu, May 28, 2009 at 7:26 PM, Chris Colman
chr...@stepaheadsoftware.com wrote:
Is that a relatively new feature because we're still on 1.4m2
I should have specified that this is with 1.4m2 circa May 2008 so it's a
fairly old version of Wicket.
If anyone could shed some light on this issue it would be very cool. Is
it worth trying the latest Wicket or is this not a bug but part of the
design?
Chris
-Original Message-
We
After web application initialization, in which WebApplication.mount() is
called on each bookmarkable page, Wicket obviously has a map of some
description to allow it to look up the mounted pages based on the path.
Is this map available to application code to look up?
My code also needs a way of
1 - 100 of 592 matches
Mail list logo
