that can be customized by css, like:
li.feedbackPanelERROR {
background-image: url(../images/warn.gif) ;
padding-left: 25px;
background-repeat: no-repeat;
background-position: 5px;
list-style-type: none;
}
FeedbackPanel will generate feedbackPanelERROR/feedbackPanelINFO class for
Hi all,
just a quick post to say that this morning I've moved the
wicket-javaEE integration module to the wicket-stuff svn repository.
More details about this project are available at:
http://code.google.com/p/fdiotalevi/wiki/WicketJavaEEIntegration
The complete url to checkout the module is
Hi Filippo,
just browsed through it and its really nice work. Especially if someone
wants to have EJB3 persitence but not to use EJB3 Stateless Session Beans to
query it.
However, the thing with the EjbAnnotation looks not so clear to me - i mean,
every IDE has J5EE support and so in Neatbeans
On 12/28/06, Korbinian Bachl [EMAIL PROTECTED] wrote:
Hi Filippo,
just browsed through it and its really nice work. Especially if someone
wants to have EJB3 persitence but not to use EJB3 Stateless Session Beans to
query it.
However, the thing with the EjbAnnotation looks not so clear to me
and completely dynamic layout can also be done with the use of panels.
So your basepage only has the portions filled in where the panels are
placed.
But the my question is shouldn't you just make different pages?
johan
On 12/28/06, Carfield Yim [EMAIL PROTECTED] wrote:
I feel using Markup
lets not forget the important part, assuming the ejb thing works just like
wicket-spring. things injected are actually proxies not beans themselves.
these proxies can be serialized safely - they do not have a hard link to the
underlying ejb bean. if you do not do this and keep a reference to an
I believe there you have to differate:
a; stateless-sessionbeans: those are only living for 1 method call, then
returned to the EJB-pool, so i dont see here a danger
b, stateful-sessionbeans: those are living over the request and have to be
used in your Wicketsession and referenced there, they
no, there is no difference
you do not want stateless or stateful beans to be directly referenced by
wicket components, or anything that will end up in httpsession
-igor
On 12/28/06, Korbinian Bachl [EMAIL PROTECTED] wrote:
I believe there you have to differate:
a; stateless-sessionbeans:
So both beans (statefull or stateless) are injected on every request?
On 12/28/06, Korbinian Bachl [EMAIL PROTECTED] wrote:
I believe there you have to differate:
a; stateless-sessionbeans: those are only living for 1 method call, then
returned to the EJB-pool, so i dont see here a danger
b,
well, as far as I know, statefull are recreated every JNDI lookup, so you
need to hold a reference to it, as long as you need it - the other is not
supposed to live longer than a single method call
I usually use them in a LoadableDataProvider or a LoadableModel, never tried
them direct in Pages
Can you please tell me how you mean directly referenced ? - and how
indirectly referenced should be?
Thanks in advance
_
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Igor
Vaynberg
Gesendet: Donnerstag, 28. Dezember 2006 18:14
An: wicket-user@lists.sourceforge.net
If you have a model like this:
class LoadableModel
{
private EjbBean bean;
}
then this could be a problem
because it should be something like this:
class LoadableModel
{
private EjbBeanProxy bean;
}
and proxy something like this:
class EjbBeanProxy
{
transient EjbBean bean;
String jndiname
On 12/28/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
lets not forget the important part, assuming the ejb thing works just like
wicket-spring. things injected are actually proxies not beans themselves.
Yes Igor, I've used the same technique you adopted in the Wicket
Spring integration. Things
Greetings,
I have been trying to work with the StringHeaderContributors. However, I have
observed a rather strange behavior while using Wicket 1.2.3. The header
contributions seem to be appearing and disappearing randomly. I have tested a
class for a simple webpage (see below) with a
have you tried 1.2.4?
-igor
On 12/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Greetings,
I have been trying to work with the StringHeaderContributors. However, I
have observed a rather strange behavior while using Wicket 1.2.3. The
header contributions seem to be appearing and
Yes, I have tried this new version too, but the problem seems to persist. I
have noticed some backports in the AbstractBehavior class, could this be the
cause/solution?
igor.vaynberg wrote:
have you tried 1.2.4?
-igor
On 12/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I could make '/folder-name1/mount/path' the complete mount however I would
need to do this for about 100 different folder names.
Perhaps it would be helpful to know what my end goal is... I would like
/context-name/folder-name1/something to end up in a render where
component.getVariation()
With an eye toward cutting energy usage and the resulting reduction of
pollutants in the air and water, we're excited by the positive impact
each item brings to the environment. Scoring data only when needed
assures "fresh," up-to-date results. After the company critically
reviewed its
i have just migrated wicket 2.0 from commons-logging to slf4j as was
previously discussed and agreed upon.
people using 2.0 need to add the following to their project's pom or
equivalent:
if you are using commons-logging:
dependency
groupIdorg.slf4j/groupId
19 matches
Mail list logo
