Re: instantiate panels in a spring bean

[Arjun Dhar]

May or may not be consequential, why is "myInit" not public? 
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/instantiate-panels-in-a-spring-bean-tp2946859p2953812.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: New App - Best Practices

[Brian Topping]

On Oct 3, 2010, at 11:58 PM, Sam Stainsby wrote:

>> In any case coding to a standard persistence interface (JDO) 
>> over a proprietary API is IMHO an insurance policy
> 
> I can understand that, and I think that way too in some situations, but I 
> reject the notion that there is no price to pay.

This is where the old "Total Cost of Ownership" comes in to play.  The right 
technology for a particular developer or team is going to be the one that 
allows the problem domain to be solved with the least cost.  

For some developers, a lack of documentation or online examples is might cost 
more in lost time than the additional cost of laboriously setting up JPA and 
all the requisite annotations.  For others, unlearning their old habits might 
be a huge cost.  In a team environment, change can lead to politics, another 
cost.  As a project grows to include a team, potential difficulty in hiring new 
staff that is receptive to the chosen technologies also needs to be considered 
briefly (Wicket itself had this issue until recently).

There's *always* a cost, but which one is cheapest (most efficient, easiest to 
use, yada yada) in the end depends on a lot of localized factors.  If it did 
not, there would be a website that every developer visited before starting a 
new project, and the anointed "best technologies" for that moment would be 
listed there.  Heck, you would be able check boxes on the list and generate a 
POM from it...

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

Re: New App - Best Practices

[Sam Stainsby]

On Mon, 04 Oct 2010 12:59:43 +1000, Chris Colman wrote:

>>Keep in mind though that adding a layer like this over DB4O will mostly
>>remove the advantages that would make you want to choose DB4O in the
>>first place.
> 
> Not really AFAIK: The ability to not have to manage fetch depths that
> JDO/DB40 gives you over raw DB40 gives you is a massive productivity
> boost (not sure if the latest DB40 supports lazy loading or not yet).

This is OT, but I feel it needs some correction.

DB4O has had transparent activation (automatic loading of references if/
when needed) and transparent persistence (automatic update depth) for a 
while now. You byte code can even be automatically instrumented with TA/TP
(but note code injection doesn't work with Scala, so we hand-code a few 
base relationship classes with TA instead).

You are missing out on the main goal of DB4O: simplicity - the ability to 
store and query POJOs with zero configuration, even POJOs from other 
database-unaware APIs.

You are also missing out on advantages like automatic schema updates, 
DB4O's own unique ID system, and other very useful parts of the DB4O API.

> In any case coding to a standard persistence interface (JDO) 
> over a proprietary API is IMHO an insurance policy

I can understand that, and I think that way too in some situations, but I 
reject the notion that there is no price to pay.


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

Re: New App - Best Practices

[James Carman]

Make sure your Manning books don't already come with the free PDF version
before you spring (couldn't resist) for it.  When I get them from Amazon,
they sometimes come with an insert that allows you to download the PDF.
On Oct 3, 2010 11:35 PM, "Brian Topping"  wrote:
>
> On Oct 3, 2010, at 11:19 PM, Jeremy Thomerson wrote:
>
>> On Sun, Oct 3, 2010 at 9:17 PM, Brian Topping 
wrote:
>>
>>> If you want to use Spring, read the first chapter of the reference, skip
to
>>> the database chapter, THEN skip back as necessary to fill in the gaps on
how
>>> to set up the database. That's the fastest way to learn it.
>>
>>
>> I've worked with Brian on other projects, and he is very good with
>> architecture. His advice here is sound. I would be curious just to be
sure
>> - which reference in particular do you mean?
>
>
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/is
what I use. I'm not ashamed to say that I still use this page
frequently,
as I'm less about memorizing everything and more about knowing where to look
something up fast.
>
> As I started to think about documentation, "Wicket In Action" is a must
have. "Spring In Action" is probably just as good, the folks at Manning
would rather throw away a manuscript than release a bad one, but I haven't
read it. The paper versions are great to take to a cafe, but definitely
spend a few extra bucks on the PDF too. It's more than worth the price of a
couple of lattes!
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>

Re: New App - Best Practices

[Brian Topping]

On Oct 3, 2010, at 11:19 PM, Jeremy Thomerson wrote:

> On Sun, Oct 3, 2010 at 9:17 PM, Brian Topping  wrote:
> 
>> If you want to use Spring, read the first chapter of the reference, skip to
>> the database chapter, THEN skip back as necessary to fill in the gaps on how
>> to set up the database.  That's the fastest way to learn it.
> 
> 
> I've worked with Brian on other projects, and he is very good with
> architecture.  His advice here is sound. I would be curious just to be sure
> - which reference in particular do you mean?

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/
 is what I use.  I'm not ashamed to say that I still use this page frequently, 
as I'm less about memorizing everything and more about knowing where to look 
something up fast.  

As I started to think about documentation, "Wicket In Action" is a must have.  
"Spring In Action" is probably just as good, the folks at Manning would rather 
throw away a manuscript than release a bad one, but I haven't read it.  The 
paper versions are great to take to a cafe, but definitely spend a few extra 
bucks on the PDF too.  It's more than worth the price of a couple of lattes!
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Rendering Html on Ajax Request

[Jeremy Thomerson]

Also, you should do this instead:

add(new Label("somelable", new StringResourceModel("your-string-key")))


On Sun, Oct 3, 2010 at 9:48 PM, Mauro Ciancio wrote:

> Hello,
> This could help you,
> org.apache.wicket.Component#setEscapeModelStrings
>
> That would disable the escape of strings.
>
> Regards.
>
> On Sun, Oct 3, 2010 at 11:21 PM,   wrote:
> > Hi All,
> >
> >
> > I have some property define in property file like below
> >
> > Myproperty.name = This is bold
> >
> > And on some Ajax request I am adding  this property to some label like
> this
> >
> > add(new Label("somelable", getLocalizer().getString("Myproperty.name."))
> >
> >
> > My problem is , html  tags are rendered as text and  I am not getting
> bold effect or any Html formatting.
> >
> >
> > Hope someone know how to fix this.
> >
> > Thanks
> >
> >
> >
> >
>
>
>
> --
> Mauro Ciancio
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Jeremy Thomerson
http://www.wickettraining.com

Re: New App - Best Practices

[Jeremy Thomerson]

On Sun, Oct 3, 2010 at 9:17 PM, Brian Topping  wrote:

> If you want to use Spring, read the first chapter of the reference, skip to
> the database chapter, THEN skip back as necessary to fill in the gaps on how
> to set up the database.  That's the fastest way to learn it.


I've worked with Brian on other projects, and he is very good with
architecture.  His advice here is sound. I would be curious just to be sure
- which reference in particular do you mean?

-- 
Jeremy Thomerson
http://www.wickettraining.com

Re: JFreeChart with clickable imagemap

[James]

Dear all,

I've added a new wiki page "JFreeChart with tooltip
example",
which outlines the steps to follow to create JFreeChart based charts that
can display tooltips.

On Fri, Oct 1, 2010 at 3:05 PM, James  wrote:

> Thanks Ernesto.
> I'll do the same.
>
>
> On Fri, Oct 1, 2010 at 2:24 PM, Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
>> James,
>>
>> why not add this "bit" to the wiki page you mentioned? So that others
>> can avoid loosing the hours you lost;-)
>>
>> Cheers,
>>
>> Ernesto
>>
>> On Fri, Oct 1, 2010 at 8:18 AM, James  wrote:
>> > Guys,
>> >
>> > Finally managed to display the tooltip generated by JFreeChart in the
>> wicket
>> > page by following these
>> > instructions<
>> http://markmail.org/message/r36cvdt2o3c4pki6#query:wicket%20jfreechart%20tooltips+page:1+mid:xqpnjdsj2lnkoinq+state:results
>> >
>> > .
>> > Had only an example markup been given in that post, it would have saved
>> lots
>> > of frustrating hours I spent. :-(
>> >
>> > For anyone looking forward for showing the tooltips in a chart generated
>> by
>> > JFreeChart, here is the markup you might need.
>> >
>> > 
>> >
>> > 
>> >
>> > For the java part, use this
>> > code<
>> http://markmail.org/message/r36cvdt2o3c4pki6#query:wicket%20jfreechart%20tooltips+page:1+mid:xqpnjdsj2lnkoinq+state:results
>> >
>> > .
>> >
>> > Your output should look something like this..
>> >
>> > 
>> >   
>> >   
>> >
>> >   
>> > 
>> >
>> >
>> > NOTE:
>> >
>> >  - You must use  
>> >  and not  
>> 
>> >  - You must use the "#" symbol before the "usemap" id.
>> >  - The image map related html markup is generated by the api provided by
>> > JFreeChart.
>> >
>> >
>> >
>> > On Fri, Oct 1, 2010 at 10:34 AM, James 
>> wrote:
>> >
>> >> Hi Peter,
>> >>
>> >> Thanks for your prompt reply.
>> >> I don't know how I missed this wonderful mailing list for this long..
>> ;-(
>> >>
>> >> I have tried passing models to constructImageMap (wrapping the chart
>> image
>> >> object as a model) but somehow the map was not updated.
>> >>
>> >> I checked jetwick and it looks cool. ;-)
>> >> Do you use JFreeChart to create those charts?
>> >> I'm willing to try that option as well. Kindly blog about it!
>> >>
>> >> Thanks once again for taking your time to reply.
>> >>
>> >>
>> >> On Thu, Sep 30, 2010 at 7:27 PM, Peter Karich 
>> wrote:
>> >>
>> >>> Hi James,
>> >>>
>> >>> In the constructImageMap you whill have to pass a model as well, but
>> I'm
>> >>> not sure how :-(
>> >>>
>> >>> Another way would be to adapt constructImageMap to updateImageMap
>> >>> so that you can call it in ChartImage.createBufferedImage (or every
>> time
>> >>> the model updates)
>> >>>
>> >>> BTW: For jetwick I used an html solution with div's to display bar
>> charts.
>> >>> which is customizable by the designer (if any ;-)), readable by
>> spiders
>> >>> etc
>> >>> and didn't need those imagemaps. Are you interested in this solution?
>> I
>> >>> could blog about it.
>> >>>
>> >>> Regards,
>> >>> Peter (aka timetabling on twitter ;-)).
>> >>>
>> >>> > Hi Guys,
>> >>> >
>> >>> > I followed the instructions in the wiki "JFreeChart with clickable
>> >>> > imagemap<
>> >>>
>> https://cwiki.apache.org/WICKET/jfreechart-with-clickable-imagemap.html>"
>> >>> > to create a chart.
>> >>> > I have a requirement whereby the chart has to be generated
>> dynamically
>> >>> based
>> >>> > on certain inputs.
>> >>> > I managed to create the chart image by using LoadableDetachableModel
>> but
>> >>> > struggling to get the imagemap updated as the chart image changes.
>> >>> > Kindly give your valuable suggestions.
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>> -
>> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >>> For additional commands, e-mail: users-h...@wicket.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Thanks & Regards,
>> >> James
>> >>
>> >
>> >
>> >
>> > --
>> > Thanks & Regards,
>> > James
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
> --
> Thanks & Regards,
> James
>



-- 
Thanks & Regards,
James

RE: New App - Best Practices

[Chris Colman]

>> Forgot to mention: DataNucleus allows you to use a wide range of
>> datastores and switch between them without any code changes: eg., all
>> the usual RDBMSes (MySQL, Oracle etc.,), Object Databases (DB4O and
some
>> others), Google Application Engine (GAE), LDAP, Excel plus loads
more.
>> If you don't want to commit to an ORM/RDBMS then DN would provide
that
>> level of protection against datastore 'lock in'.
>
>Keep in mind though that adding a layer like this over DB4O will mostly
>remove the advantages that would make you want to choose DB4O in the
>first place.

Not really AFAIK: The ability to not have to manage fetch depths that
JDO/DB40 gives you over raw DB40 gives you is a massive productivity
boost (not sure if the latest DB40 supports lazy loading or not yet). In
any case coding to a standard persistence interface (JDO) over a
proprietary API is IMHO an insurance policy I am prepared to invest in
given the performance overheads are so miniscule.

... but this is probably a discussion best held elsewhere... I think we
all agree in terms of UI frameworks Wicket is definitely the best there
is!

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

Re: Rendering Html on Ajax Request

[Mauro Ciancio]

Hello,
This could help you,
org.apache.wicket.Component#setEscapeModelStrings

That would disable the escape of strings.

Regards.

On Sun, Oct 3, 2010 at 11:21 PM,   wrote:
> Hi All,
>
>
> I have some property define in property file like below
>
> Myproperty.name = This is bold
>
> And on some Ajax request I am adding  this property to some label like this
>
> add(new Label("somelable", getLocalizer().getString("Myproperty.name."))
>
>
> My problem is , html  tags are rendered as text and  I am not getting bold 
> effect or any Html formatting.
>
>
> Hope someone know how to fix this.
>
> Thanks
>
>
>
>



-- 
Mauro Ciancio

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

Rendering Html on Ajax Request

[Gurpreet.Singh]

Hi All,


I have some property define in property file like below

Myproperty.name = This is bold

And on some Ajax request I am adding  this property to some label like this

add(new Label("somelable", getLocalizer().getString("Myproperty.name."))


My problem is , html  tags are rendered as text and  I am not getting bold 
effect or any Html formatting.


Hope someone know how to fix this.

Thanks

Re: New App - Best Practices

[Brian Topping]

I personally use Wicket / Spring / JPA Hibernate / PostgreSQL.  Hibernate 
because I know how to tune it and I'm too busy learning other new technologies 
to focus on replacing one that is working for my needs now.  Spring because it 
helps immensely with unit testing and marginally by promoting good patterns 
(note these are two "nice to have" but not critical requirements for a small 
project).  I'd have to agree with the previous poster that Wicket is the one 
tried and true, money back guaranteed must have technology in the entire stack.

If you are just learning ORM for the first time, DataNucleus does look like a 
better way to go.

I would focus more on patterns and interfaces than on technologies.  Liberal 
use of patterns will keep your code honest and help you to refactor out or in 
technologies as necessary in the future.  Interfaces can always be extracted 
later, but having replaceable implementations are a huge benefit for migration 
between technologies.  You'll never get the perfect mix of technologies because 
they change all the time, but your application's domain focus will change very 
little.  The name of the game is to keep these realms as separate as possible.

One thing about Spring for a beginner is that you don't absolutely need it to 
get started with.  It's a big framework and it's core competency is dependency 
injection.  OTOH, the biggest thing it provides for small projects is a stable 
and well-maintained framework for database transactions.  If you want to use 
Spring, read the first chapter of the reference, skip to the database chapter, 
THEN skip back as necessary to fill in the gaps on how to set up the database.  
That's the fastest way to learn it.  Once you get started with it, the learning 
comes naturally.  If you use Spring, immediately learn the @SpringBean 
annotation in Wicket.

Good luck!

Brian

On Oct 3, 2010, at 7:40 PM, Francisco Diaz Trepat - gmail wrote:

> Hi I've tested wicket before it was in the apache incubator and found
> it to be awesome, since then we have adopted it and I have been
> migrating all legacy applications for my company for the last 3 years
> aprox.
> 
> Now I have to build a small app to manage small accounting and
> logistics for my wife's Business
> 
> She is opening a small printing shop for small business labels, such
> as wine bottle labels, clothing labels, bags, etc.
> 
> At work I use wicket with an "ingenious" CORBA server, courtesy of the
> legacy applications.
> 
> Now I am free to do whatever I want. This is the worst part. :-)
> 
> I would like to help out and test maybe wicket 1.5 and some good
> database solution.
> 
> Can you share some comments or recommendations on what to do?
> For Instance, I once read about Active Objects, I pretty much liked
> the idea and built some prototypes, but now the site is exactly the
> same and found their latest released is from 2008. So that is no so
> edgy...
> 
> I don't wish to use hibernate, but could be some other "object
> relational mapping", even hibernate if you insist... :-)
> 
> So, ideas on what to use?
> 
> UI = Wicket.
>+ 1.4?
>+ 1.5?
> middle layer?
> Persistence?
> 
> Thanks in advance,
> f(t)
> 
> -
> 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: New App - Best Practices

[Sam Stainsby]

On Mon, 04 Oct 2010 11:36:48 +1000, Chris Colman wrote:


> Forgot to mention: DataNucleus allows you to use a wide range of
> datastores and switch between them without any code changes: eg., all
> the usual RDBMSes (MySQL, Oracle etc.,), Object Databases (DB4O and some
> others), Google Application Engine (GAE), LDAP, Excel plus loads more.
> If you don't want to commit to an ORM/RDBMS then DN would provide that
> level of protection against datastore 'lock in'.

Keep in mind though that adding a layer like this over DB4O will mostly 
remove the advantages that would make you want to choose DB4O in the 
first place.


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

Re: New App - Best Practices

[7zark7]

There's no "best practices" any more :-)

Wicket/Spring/Hibernate is simple and lots of examples.
Hibernate with JPA is super-easy to work with.

If you want something "different", NoSQL such as CouchDB is nice, 
especially if you need to store binary attachments, etc.


My current stack is Wicket/Spring/CouchDB using Scala - but the only 
100%, mathematically-proven to be superior technology in this is Wicket ;-)



On 10/3/10 4:40 PM, Francisco Diaz Trepat - gmail wrote:

Hi I've tested wicket before it was in the apache incubator and found
it to be awesome, since then we have adopted it and I have been
migrating all legacy applications for my company for the last 3 years
aprox.

Now I have to build a small app to manage small accounting and
logistics for my wife's Business

She is opening a small printing shop for small business labels, such
as wine bottle labels, clothing labels, bags, etc.

At work I use wicket with an "ingenious" CORBA server, courtesy of the
legacy applications.

Now I am free to do whatever I want. This is the worst part. :-)

I would like to help out and test maybe wicket 1.5 and some good
database solution.

Can you share some comments or recommendations on what to do?
For Instance, I once read about Active Objects, I pretty much liked
the idea and built some prototypes, but now the site is exactly the
same and found their latest released is from 2008. So that is no so
edgy...

I don't wish to use hibernate, but could be some other "object
relational mapping", even hibernate if you insist... :-)

So, ideas on what to use?

UI = Wicket.
 + 1.4?
 + 1.5?
middle layer?
Persistence?

Thanks in advance,
f(t)

-
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: New App - Best Practices

[Chris Colman]

>> So, ideas on what to use?
>
>If you want to avoid ORMs completely, you could consider an object
>database like DB4O as we have in Granite. Granite is currently is not
>quite complete and poorly documented, and written Scala not Java, but
>there is surely something you can use there if you want to go down a
that
>path - even if its just ideas and sample code.

Forgot to mention: DataNucleus allows you to use a wide range of
datastores and switch between them without any code changes: eg., all
the usual RDBMSes (MySQL, Oracle etc.,), Object Databases (DB4O and some
others), Google Application Engine (GAE), LDAP, Excel plus loads more.
If you don't want to commit to an ORM/RDBMS then DN would provide that
level of protection against datastore 'lock in'.

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

RE: New App - Best Practices

[Chris Colman]

We use Wicket with DataNucleus (JDO) www.datanucleus.org as the
persistence layer. The persistence side is truly transparent and it
performs really well - your model objects don't need any extra methods
and you are free to model and code just as if you were dealing with an
'in memory' only set of objects.

We also use the 'Exposed Domain Model' pattern/strategy which is another
productivity boost over many of the other more traditional approaches to
persistence.

Regards,
Chris

>-Original Message-
>From: Francisco Diaz Trepat - gmail
[mailto:francisco.diaztre...@gmail.com]
>Sent: Monday, 4 October 2010 10:40 AM
>To: Wicket-Users
>Subject: New App - Best Practices
>
>Hi I've tested wicket before it was in the apache incubator and found
>it to be awesome, since then we have adopted it and I have been
>migrating all legacy applications for my company for the last 3 years
>aprox.
>
>Now I have to build a small app to manage small accounting and
>logistics for my wife's Business
>
>She is opening a small printing shop for small business labels, such
>as wine bottle labels, clothing labels, bags, etc.
>
>At work I use wicket with an "ingenious" CORBA server, courtesy of the
>legacy applications.
>
>Now I am free to do whatever I want. This is the worst part. :-)
>
>I would like to help out and test maybe wicket 1.5 and some good
>database solution.
>
>Can you share some comments or recommendations on what to do?
>For Instance, I once read about Active Objects, I pretty much liked
>the idea and built some prototypes, but now the site is exactly the
>same and found their latest released is from 2008. So that is no so
>edgy...
>
>I don't wish to use hibernate, but could be some other "object
>relational mapping", even hibernate if you insist... :-)
>
>So, ideas on what to use?
>
>UI = Wicket.
>+ 1.4?
>+ 1.5?
>middle layer?
>Persistence?
>
>Thanks in advance,
>f(t)
>
>-
>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: New App - Best Practices

[Sam Stainsby]

On Sun, 03 Oct 2010 20:40:04 -0300, Francisco Diaz Trepat - gmail wrote:

> Now I am free to do whatever I want. This is the worst part. :-)

I understand that feeling! When I started designing our web app 
framework, I picked the technologies from an enormous set of options that 
I thought would make app development as rapid and robust as possible. The 
title of your message "best practices" suggests though that you want to 
stick to the mainstream solutions.

> So, ideas on what to use?

If you want to avoid ORMs completely, you could consider an object 
database like DB4O as we have in Granite. Granite is currently is not 
quite complete and poorly documented, and written Scala not Java, but 
there is surely something you can use there if you want to go down a that 
path - even if its just ideas and sample code.


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

Re: New App - Best Practices

[Jeremy Thomerson]

>
> So, ideas on what to use?
>
> UI = Wicket.
>+ 1.4?
>+ 1.5?
> middle layer?
> Persistence?
>

Wicket / Spring / Hibernate is a very common setup, so you will have an easy
time finding examples, help, etc.

-- 
Jeremy Thomerson
http://www.wickettraining.com

New App - Best Practices

[Francisco Diaz Trepat - gmail]

Hi I've tested wicket before it was in the apache incubator and found
it to be awesome, since then we have adopted it and I have been
migrating all legacy applications for my company for the last 3 years
aprox.

Now I have to build a small app to manage small accounting and
logistics for my wife's Business

She is opening a small printing shop for small business labels, such
as wine bottle labels, clothing labels, bags, etc.

At work I use wicket with an "ingenious" CORBA server, courtesy of the
legacy applications.

Now I am free to do whatever I want. This is the worst part. :-)

I would like to help out and test maybe wicket 1.5 and some good
database solution.

Can you share some comments or recommendations on what to do?
For Instance, I once read about Active Objects, I pretty much liked
the idea and built some prototypes, but now the site is exactly the
same and found their latest released is from 2008. So that is no so
edgy...

I don't wish to use hibernate, but could be some other "object
relational mapping", even hibernate if you insist... :-)

So, ideas on what to use?

UI = Wicket.
+ 1.4?
+ 1.5?
middle layer?
Persistence?

Thanks in advance,
f(t)

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

Re: chrome + wicket ajax + back button = problem?

[Ryan Crumley]

Just to clarify:

The page in the example link I sent is stateless (it's static html). The
other point is that Chrome and IE do not fetch the original page on back
button click. They are serving the original html straight from the cache
(without the DOM modifications).

It sounds like the only "fix" is to update the page headers so that no
browser will ever cache the page. That seems like an overkill but so far I
haven't found any other solution that works across browsers. This seems like
a very common scenario... is it also very common to set all the no-cache
headers?

Ryan

On Sun, Oct 3, 2010 at 5:56 PM, Zilvinas Vilutis  wrote:

> Yes, it is not repeatable on FF because FF does page caching which IE
> does not for "Back" history.
>
> Your page must be stateless on the server side.
>
> Žilvinas Vilutis
>
> Mobile:   (+370) 652 38353
> E-mail:   cika...@gmail.com
>
>
>
> On Sun, Oct 3, 2010 at 3:47 PM, Ryan Crumley  wrote:
> > What is interesting is this is not a wicket specific issue however it is
> > more serious when using wicket than other frameworks due to the expired
> > links causing errors when they reappear.
> >
> > I created a very simple version of the problem. Chrome and IE8 exhibits
> the
> > problem but Firefox and Safari do not:
> >
> > http://www.cupofcrumley.com/chrome-test/Page1.html
> >
> > Ryan
> >
> > On Fri, Sep 24, 2010 at 1:48 AM, Peter Karich  wrote:
> >
> >> I had the same problem ...
> >> > Take a look at
> >> >
> >>
> http://www.richardnichols.net/2010/03/apache-wicket-force-page-reload-to-fix-ajax-back/
> >> >
> >>
> >> isn't there a better fix? E.g. it seems to me that this 'hack' avoids
> >> client-side js caching (or is this a wrong observation)?
> >>
> >> Regards,
> >> Peter.
> >>
> >>
> >>
> >>
> >> --
> >> http://jetwick.com twitter search prototype
> >>
> >>
> >> -
> >> 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: instantiate panels in a spring bean

[fachhoch]

Actually this is groovy script, I load this using   spring lang tags




 


please  help me.

-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/instantiate-panels-in-a-spring-bean-tp2946859p2953634.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: chrome + wicket ajax + back button = problem?

[Zilvinas Vilutis]

Yes, it is not repeatable on FF because FF does page caching which IE
does not for "Back" history.

Your page must be stateless on the server side.

Žilvinas Vilutis

Mobile:   (+370) 652 38353
E-mail:   cika...@gmail.com



On Sun, Oct 3, 2010 at 3:47 PM, Ryan Crumley  wrote:
> What is interesting is this is not a wicket specific issue however it is
> more serious when using wicket than other frameworks due to the expired
> links causing errors when they reappear.
>
> I created a very simple version of the problem. Chrome and IE8 exhibits the
> problem but Firefox and Safari do not:
>
> http://www.cupofcrumley.com/chrome-test/Page1.html
>
> Ryan
>
> On Fri, Sep 24, 2010 at 1:48 AM, Peter Karich  wrote:
>
>> I had the same problem ...
>> > Take a look at
>> >
>> http://www.richardnichols.net/2010/03/apache-wicket-force-page-reload-to-fix-ajax-back/
>> >
>>
>> isn't there a better fix? E.g. it seems to me that this 'hack' avoids
>> client-side js caching (or is this a wrong observation)?
>>
>> Regards,
>> Peter.
>>
>>
>>
>>
>> --
>> http://jetwick.com twitter search prototype
>>
>>
>> -
>> 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: chrome + wicket ajax + back button = problem?

[Ryan Crumley]

What is interesting is this is not a wicket specific issue however it is
more serious when using wicket than other frameworks due to the expired
links causing errors when they reappear.

I created a very simple version of the problem. Chrome and IE8 exhibits the
problem but Firefox and Safari do not:

http://www.cupofcrumley.com/chrome-test/Page1.html

Ryan

On Fri, Sep 24, 2010 at 1:48 AM, Peter Karich  wrote:

> I had the same problem ...
> > Take a look at
> >
> http://www.richardnichols.net/2010/03/apache-wicket-force-page-reload-to-fix-ajax-back/
> >
>
> isn't there a better fix? E.g. it seems to me that this 'hack' avoids
> client-side js caching (or is this a wrong observation)?
>
> Regards,
> Peter.
>
>
>
>
> --
> http://jetwick.com twitter search prototype
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: StatelessLink

[Altuğ Bilgin Altıntaş]

Problem occurs because of Spring integration; I called Service like that

final SupplierService supplierService = (SupplierService)
LazyInitProxyFactory.createProxy(SupplierService.class, new
IProxyTargetLocator() {
public Object locateProxyTarget() {
return ((WicketApplication) Application.get()).

getSpringContextLocator().getSpringContext().getBean("supplierService");

}
} );

Now It works.

I know i can use @SpringBean...

Thanks.

AOP trigerred when get

2010/10/3 Jeremy Thomerson 

> Show your link code. You're obviously holding a reference to the aspect,
> which can't be serialized.
>
> Jeremy Thomerson
> http://wickettraining.com
> -- sent from my "smart" phone, so please excuse spelling, formatting, or
> compiler errors
>
> On Oct 3, 2010 2:16 PM, "Altuğ Bilgin Altıntaş"  wrote:
>
> I found the problem (not solution yet)
>
> Spring's AOP config  :
>
>   
>   
>  expression="execution(boolean org.jtpd.data..*(..))" />
>   
>   
>   
>
> For logging and when i search logs i see :
>
> org.apache.wicket.util.io.SerializableChecker$*
> WicketNotSerializableException*: Unable to serialize class:
> org.springframework.aop.aspectj.AspectJPointcutAdvisor
>
> AspectJPointcutAdvisor can not serializable so StatelessLink doesn't work
> and i always get Page Expired Error when exporting CSV file via using
> WebResponse.
>
> Any comment on that ?
>
>
>
> 2010/9/28 Igor Vaynberg 
>
>
> > even if the page is stateful, the url the stateless link generates
> > should be stateless...got a ...
>

Re: StatelessLink

[Jeremy Thomerson]

Show your link code. You're obviously holding a reference to the aspect,
which can't be serialized.

Jeremy Thomerson
http://wickettraining.com
-- sent from my "smart" phone, so please excuse spelling, formatting, or
compiler errors

On Oct 3, 2010 2:16 PM, "Altuğ Bilgin Altıntaş"  wrote:

I found the problem (not solution yet)

Spring's AOP config  :

   
   
   
   
   
   

For logging and when i search logs i see :

org.apache.wicket.util.io.SerializableChecker$*
WicketNotSerializableException*: Unable to serialize class:
org.springframework.aop.aspectj.AspectJPointcutAdvisor

AspectJPointcutAdvisor can not serializable so StatelessLink doesn't work
and i always get Page Expired Error when exporting CSV file via using
WebResponse.

Any comment on that ?



2010/9/28 Igor Vaynberg 


> even if the page is stateful, the url the stateless link generates
> should be stateless...got a ...

Re: StatelessLink

[Altuğ Bilgin Altıntaş]

I found the problem (not solution yet)

Spring's AOP config  :








For logging and when i search logs i see :

org.apache.wicket.util.io.SerializableChecker$*
WicketNotSerializableException*: Unable to serialize class:
org.springframework.aop.aspectj.AspectJPointcutAdvisor

AspectJPointcutAdvisor can not serializable so StatelessLink doesn't work
and i always get Page Expired Error when exporting CSV file via using
WebResponse.

Any comment on that ?



2010/9/28 Igor Vaynberg 

> even if the page is stateful, the url the stateless link generates
> should be stateless...got a quickstart?
>
> -igor
>
> On Tue, Sep 28, 2010 at 2:09 AM, Martin Grigorov 
> wrote:
> > You may use wicket-devutils. There is a stateless checker. It will tell
> you
> > which component makes the page stateful.
> >
> > 2010/9/28 Altuğ Bilgin Altıntaş 
> >
> >> Hi ;
> >>
> >> I used StatelessLink but i still get Page Expired , is it normal ?
> >>
> >> Also this StatelessLink is in StatelessForm and Page is Bookmarkable but
> >> wicket - 1.4.9 still generates :
> >>
> >>
> >>
> http://localhost:8080/ac/customer?wicket:interface=:1:frmSearch:linkExcel::ILinkListener
> >> ::
> >>
> >> why ?
> >>
> >> Thanks.
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: instantiate panels in a spring bean

[Ben Tilford]

What are you using to build the project? If your doing stub generation
(mixed java & groovy project) see if the stubs look right. There are a
few bugs in the stub generator when dealing with inner classes but it
shouldn't have compiled in that case.

On 10/2/10, fachhoch  wrote:
>
> I added super for subclasses it still did not work , as I said it worked
> with
> java the same code when comming from .groovy should work right ?  if it is
> not do I have to give some special treatment for wicket groovy compoments ?
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/instantiate-panels-in-a-spring-bean-tp2946859p2952942.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

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

Re: Wicket 1.5 and OSGi

[Martin Grigorov]

Hi Eike,

Please file a bug in Jira with link to this mail thread.

On Sun, Oct 3, 2010 at 2:33 PM, Eike Kettner  wrote:

> Hi Martin
>
> thanks for your advice. I didn't know the maven-shade-plugin, but I
> create on big wicket jar containing all wicket jars like wicket-request,
> wicket-xyz with pax:wrap-jar. This also works fine.
>
> Just want to mention that with this change in wicket 1.5, wicket cannot
> be used in OSGi environments as easiliy as wicket 1.4. One usually has
> to create a wrapped jar somehow. Maybe this is worth to mention on the
> migration guide wiki page?
>
>
> On [Sun, 03.10.2010 13:59], Martin Grigorov wrote:
> > Hi Elke,
> >
> > As I said I don't use OSGi so I can say something that is against OSGi
> > rules, but here is what I'd do in your case:
> > create a Maven project (named for example 'wicket-bundle'), packaging
> type
> > 'jar' and empty src/ folder. Then use maven-shade-plugin just to produce
> one
> > bigger .jar out of all required ones (wicket-util, wicket-request,
> wicket,
> > wicket-xyz, ...) and maven-bnd-plugin to add the OSGi stuff in
> > META-INF/MANIFEST.MF.
> >
> > Since Wicket's artefacts are not splitted in -api and -impl .jars I don't
> > see a reason not to mix them all in one bigger jar for OSGi environments.
> >
> > On Sun, Oct 3, 2010 at 1:48 PM, Eike Kettner  wrote:
> >
> > > Hi there,
> > >
> > > Just a few updates from my side :
> > >
> > > I recompiled wicket-trunk with changed a package structure and then my
> > > application starts happily with wicket 1.5-M21. (by the way, I'm using
> > > Apache Felix 3.0.2)
> > >
> > > I now use the workaround of wrapping the wicket jars I need into one
> > > jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but
> > > surely not as convienient as before.
> > >
> > > Is anybody having these issues with wicket 1.5+OSGi, too? Or even
> > > better, is anybody not having issues with this combination?
> > >
> > > Regards,
> > > Eike
> > >
> > > On [Fri, 01.10.2010 22:12], Eike Kettner wrote:
> > > >
> > > > Hello again,
> > > >
> > > > I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I
> > > > found some differences. For example, wicket 1.5 has a new artifact
> > > > "wicket-request" and comparing the package structure there are some
> > > > changes, which are probably related to my problem:
> > > >
> > > > wicket-1.4.12.jar:
> > > > org.apache
> > > > `-- wicket
> > > > |-- authorization
> > > > |   |-- Action.java
> > > > |   |-- AuthorizationException.java
> > > > |   |-- strategies
> > > > |   |   |-- action
> > > > |   |   |   |-- ActionAuthorizationStrategy.java
> > > > |   |   |   `-- IActionAuthorizer.java
> > > > |   |   |-- CompoundAuthorizationStrategy.java
> > > > |   |   `-- page
> > > > |   |   |-- AbstractPageAuthorizationStrategy.java
> > > > |   |   `-- SimplePageAuthorizationStrategy.java
> > > > |   |-- UnauthorizedActionException.java
> > > > |   `-- UnauthorizedInstantiationException.java
> > > >
> > > >
> > > > wicket-auth-roles-1.4.12.jar:
> > > > org.apache
> > > > `-- wicket
> > > >|-- authentication
> > > >|   |-- AuthenticatedWebApplication.java
> > > >|   |-- AuthenticatedWebSession.java
> > > >|   |-- pages
> > > >|   |   |-- SignInPage_fr.html
> > > >`-- authorization
> > > >`-- strategies
> > > >`-- role
> > > >|-- AbstractRoleAuthorizationStrategy.java
> > > >|   |-- ActionPermissions.java
> > > >`-- Roles.java
> > > >
> > > > This looks good to OSGi as the classes are in disjoint packages in
> the
> > > > two bundles.
> > > >
> > > >
> > > > This changed in 1.5. There the structure looks like this:
> > > >
> > > > wicket-1.5-M2.1.jar
> > > > org.apache
> > > > `-- wicket
> > > > |-- authentication
> > > > |   |-- IAuthenticationStrategy.java
> > > > |   `-- strategy
> > > > |   |-- DefaultAuthenticationStrategy.java
> > > > |   `-- NoOpAuthenticationStrategy.java
> > > >
> > > > wicket-auth-roles-1.5-M2.1.jar
> > > > org.apache
> > > > `-- wicket
> > > > |-- authentication
> > > > |   |-- AuthenticatedWebApplication.java
> > > > |   |-- AuthenticatedWebSession.java
> > > > |   |-- pages
> > > > |   |   |-- SignInPage.html
> > > > |   |   |-- SignInPage.java
> > > >
> > > >
> > > > The problem is the package org.apache.wicket.authentication now,
> because
> > > > the bundle wicket-1.5-M2.1 and wicket-auth-roles-1.5-M2.1 provide
> > > > classes from this package. The same refers to
> org.apache.wicket.request,
> > > > which is exported by wicket-request and wicket in 1.5. This leads to
> > > > problems in an OSGi environment. OSGi discourages those scenarios,
> but
> > > > still offers an solution for this. A (rather old) blog post on
> osgi.org
> > > > gives some hints on this:
> > > >
> > > >
> http://www.osgi.org/blog/2006/04/misconceptions-about-osgi

Re: Wicket 1.5 and OSGi

[Eike Kettner]

Hi Martin

thanks for your advice. I didn't know the maven-shade-plugin, but I
create on big wicket jar containing all wicket jars like wicket-request,
wicket-xyz with pax:wrap-jar. This also works fine.

Just want to mention that with this change in wicket 1.5, wicket cannot
be used in OSGi environments as easiliy as wicket 1.4. One usually has
to create a wrapped jar somehow. Maybe this is worth to mention on the
migration guide wiki page?


On [Sun, 03.10.2010 13:59], Martin Grigorov wrote:
> Hi Elke,
> 
> As I said I don't use OSGi so I can say something that is against OSGi
> rules, but here is what I'd do in your case:
> create a Maven project (named for example 'wicket-bundle'), packaging type
> 'jar' and empty src/ folder. Then use maven-shade-plugin just to produce one
> bigger .jar out of all required ones (wicket-util, wicket-request, wicket,
> wicket-xyz, ...) and maven-bnd-plugin to add the OSGi stuff in
> META-INF/MANIFEST.MF.
> 
> Since Wicket's artefacts are not splitted in -api and -impl .jars I don't
> see a reason not to mix them all in one bigger jar for OSGi environments.
> 
> On Sun, Oct 3, 2010 at 1:48 PM, Eike Kettner  wrote:
> 
> > Hi there,
> >
> > Just a few updates from my side :
> >
> > I recompiled wicket-trunk with changed a package structure and then my
> > application starts happily with wicket 1.5-M21. (by the way, I'm using
> > Apache Felix 3.0.2)
> >
> > I now use the workaround of wrapping the wicket jars I need into one
> > jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but
> > surely not as convienient as before.
> >
> > Is anybody having these issues with wicket 1.5+OSGi, too? Or even
> > better, is anybody not having issues with this combination?
> >
> > Regards,
> > Eike
> >
> > On [Fri, 01.10.2010 22:12], Eike Kettner wrote:
> > >
> > > Hello again,
> > >
> > > I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I
> > > found some differences. For example, wicket 1.5 has a new artifact
> > > "wicket-request" and comparing the package structure there are some
> > > changes, which are probably related to my problem:
> > >
> > > wicket-1.4.12.jar:
> > > org.apache
> > > `-- wicket
> > > |-- authorization
> > > |   |-- Action.java
> > > |   |-- AuthorizationException.java
> > > |   |-- strategies
> > > |   |   |-- action
> > > |   |   |   |-- ActionAuthorizationStrategy.java
> > > |   |   |   `-- IActionAuthorizer.java
> > > |   |   |-- CompoundAuthorizationStrategy.java
> > > |   |   `-- page
> > > |   |   |-- AbstractPageAuthorizationStrategy.java
> > > |   |   `-- SimplePageAuthorizationStrategy.java
> > > |   |-- UnauthorizedActionException.java
> > > |   `-- UnauthorizedInstantiationException.java
> > >
> > >
> > > wicket-auth-roles-1.4.12.jar:
> > > org.apache
> > > `-- wicket
> > >|-- authentication
> > >|   |-- AuthenticatedWebApplication.java
> > >|   |-- AuthenticatedWebSession.java
> > >|   |-- pages
> > >|   |   |-- SignInPage_fr.html
> > >`-- authorization
> > >`-- strategies
> > >`-- role
> > >|-- AbstractRoleAuthorizationStrategy.java
> > >|   |-- ActionPermissions.java
> > >`-- Roles.java
> > >
> > > This looks good to OSGi as the classes are in disjoint packages in the
> > > two bundles.
> > >
> > >
> > > This changed in 1.5. There the structure looks like this:
> > >
> > > wicket-1.5-M2.1.jar
> > > org.apache
> > > `-- wicket
> > > |-- authentication
> > > |   |-- IAuthenticationStrategy.java
> > > |   `-- strategy
> > > |   |-- DefaultAuthenticationStrategy.java
> > > |   `-- NoOpAuthenticationStrategy.java
> > >
> > > wicket-auth-roles-1.5-M2.1.jar
> > > org.apache
> > > `-- wicket
> > > |-- authentication
> > > |   |-- AuthenticatedWebApplication.java
> > > |   |-- AuthenticatedWebSession.java
> > > |   |-- pages
> > > |   |   |-- SignInPage.html
> > > |   |   |-- SignInPage.java
> > >
> > >
> > > The problem is the package org.apache.wicket.authentication now, because
> > > the bundle wicket-1.5-M2.1 and wicket-auth-roles-1.5-M2.1 provide
> > > classes from this package. The same refers to org.apache.wicket.request,
> > > which is exported by wicket-request and wicket in 1.5. This leads to
> > > problems in an OSGi environment. OSGi discourages those scenarios, but
> > > still offers an solution for this. A (rather old) blog post on osgi.org
> > > gives some hints on this:
> > >
> > > http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html
> > >
> > > It probably gets to weird loading errors if two classes from the same
> > > package want to access each others fields or methods with package access,
> > > but come from a different classloader...
> > >
> > > I'm no OSGi expert, so I don't know the right OSGi header that solves
> > > this. Of course, a real solution would be to only have disjoint pac

Re: Wicket 1.5 and OSGi

[Eike Kettner]

Hi Martin

thanks for your advice. I didn't know the maven-shade-plugin, but I
create on big wicket jar containing all wicket jars like wicket-request,
wicket-xyz with pax:wrap-jar. This also works fine.

Just want to mention that with this change in wicket 1.5, wicket cannot
be used in OSGi environments as easiliy as wicket 1.4. One usually has
to create a wrapped jar somehow. Maybe this is worth to mention on the
migration guide wiki page?


On [Sun, 03.10.2010 13:59], Martin Grigorov wrote:
> Hi Elke,
> 
> As I said I don't use OSGi so I can say something that is against OSGi
> rules, but here is what I'd do in your case:
> create a Maven project (named for example 'wicket-bundle'), packaging type
> 'jar' and empty src/ folder. Then use maven-shade-plugin just to produce one
> bigger .jar out of all required ones (wicket-util, wicket-request, wicket,
> wicket-xyz, ...) and maven-bnd-plugin to add the OSGi stuff in
> META-INF/MANIFEST.MF.
> 
> Since Wicket's artefacts are not splitted in -api and -impl .jars I don't
> see a reason not to mix them all in one bigger jar for OSGi environments.
> 
> On Sun, Oct 3, 2010 at 1:48 PM, Eike Kettner  wrote:
> 
> > Hi there,
> >
> > Just a few updates from my side :
> >
> > I recompiled wicket-trunk with changed a package structure and then my
> > application starts happily with wicket 1.5-M21. (by the way, I'm using
> > Apache Felix 3.0.2)
> >
> > I now use the workaround of wrapping the wicket jars I need into one
> > jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but
> > surely not as convienient as before.
> >
> > Is anybody having these issues with wicket 1.5+OSGi, too? Or even
> > better, is anybody not having issues with this combination?
> >
> > Regards,
> > Eike
> >
> > On [Fri, 01.10.2010 22:12], Eike Kettner wrote:
> > >
> > > Hello again,
> > >
> > > I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I
> > > found some differences. For example, wicket 1.5 has a new artifact
> > > "wicket-request" and comparing the package structure there are some
> > > changes, which are probably related to my problem:
> > >
> > > wicket-1.4.12.jar:
> > > org.apache
> > > `-- wicket
> > > |-- authorization
> > > |   |-- Action.java
> > > |   |-- AuthorizationException.java
> > > |   |-- strategies
> > > |   |   |-- action
> > > |   |   |   |-- ActionAuthorizationStrategy.java
> > > |   |   |   `-- IActionAuthorizer.java
> > > |   |   |-- CompoundAuthorizationStrategy.java
> > > |   |   `-- page
> > > |   |   |-- AbstractPageAuthorizationStrategy.java
> > > |   |   `-- SimplePageAuthorizationStrategy.java
> > > |   |-- UnauthorizedActionException.java
> > > |   `-- UnauthorizedInstantiationException.java
> > >
> > >
> > > wicket-auth-roles-1.4.12.jar:
> > > org.apache
> > > `-- wicket
> > >|-- authentication
> > >|   |-- AuthenticatedWebApplication.java
> > >|   |-- AuthenticatedWebSession.java
> > >|   |-- pages
> > >|   |   |-- SignInPage_fr.html
> > >`-- authorization
> > >`-- strategies
> > >`-- role
> > >|-- AbstractRoleAuthorizationStrategy.java
> > >|   |-- ActionPermissions.java
> > >`-- Roles.java
> > >
> > > This looks good to OSGi as the classes are in disjoint packages in the
> > > two bundles.
> > >
> > >
> > > This changed in 1.5. There the structure looks like this:
> > >
> > > wicket-1.5-M2.1.jar
> > > org.apache
> > > `-- wicket
> > > |-- authentication
> > > |   |-- IAuthenticationStrategy.java
> > > |   `-- strategy
> > > |   |-- DefaultAuthenticationStrategy.java
> > > |   `-- NoOpAuthenticationStrategy.java
> > >
> > > wicket-auth-roles-1.5-M2.1.jar
> > > org.apache
> > > `-- wicket
> > > |-- authentication
> > > |   |-- AuthenticatedWebApplication.java
> > > |   |-- AuthenticatedWebSession.java
> > > |   |-- pages
> > > |   |   |-- SignInPage.html
> > > |   |   |-- SignInPage.java
> > >
> > >
> > > The problem is the package org.apache.wicket.authentication now, because
> > > the bundle wicket-1.5-M2.1 and wicket-auth-roles-1.5-M2.1 provide
> > > classes from this package. The same refers to org.apache.wicket.request,
> > > which is exported by wicket-request and wicket in 1.5. This leads to
> > > problems in an OSGi environment. OSGi discourages those scenarios, but
> > > still offers an solution for this. A (rather old) blog post on osgi.org
> > > gives some hints on this:
> > >
> > > http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html
> > >
> > > It probably gets to weird loading errors if two classes from the same
> > > package want to access each others fields or methods with package access,
> > > but come from a different classloader...
> > >
> > > I'm no OSGi expert, so I don't know the right OSGi header that solves
> > > this. Of course, a real solution would be to only have disjoint pac

Re: Wicket 1.5 and OSGi

[Martin Grigorov]

Hi Elke,

As I said I don't use OSGi so I can say something that is against OSGi
rules, but here is what I'd do in your case:
create a Maven project (named for example 'wicket-bundle'), packaging type
'jar' and empty src/ folder. Then use maven-shade-plugin just to produce one
bigger .jar out of all required ones (wicket-util, wicket-request, wicket,
wicket-xyz, ...) and maven-bnd-plugin to add the OSGi stuff in
META-INF/MANIFEST.MF.

Since Wicket's artefacts are not splitted in -api and -impl .jars I don't
see a reason not to mix them all in one bigger jar for OSGi environments.

On Sun, Oct 3, 2010 at 1:48 PM, Eike Kettner  wrote:

> Hi there,
>
> Just a few updates from my side :
>
> I recompiled wicket-trunk with changed a package structure and then my
> application starts happily with wicket 1.5-M21. (by the way, I'm using
> Apache Felix 3.0.2)
>
> I now use the workaround of wrapping the wicket jars I need into one
> jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but
> surely not as convienient as before.
>
> Is anybody having these issues with wicket 1.5+OSGi, too? Or even
> better, is anybody not having issues with this combination?
>
> Regards,
> Eike
>
> On [Fri, 01.10.2010 22:12], Eike Kettner wrote:
> >
> > Hello again,
> >
> > I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I
> > found some differences. For example, wicket 1.5 has a new artifact
> > "wicket-request" and comparing the package structure there are some
> > changes, which are probably related to my problem:
> >
> > wicket-1.4.12.jar:
> > org.apache
> > `-- wicket
> > |-- authorization
> > |   |-- Action.java
> > |   |-- AuthorizationException.java
> > |   |-- strategies
> > |   |   |-- action
> > |   |   |   |-- ActionAuthorizationStrategy.java
> > |   |   |   `-- IActionAuthorizer.java
> > |   |   |-- CompoundAuthorizationStrategy.java
> > |   |   `-- page
> > |   |   |-- AbstractPageAuthorizationStrategy.java
> > |   |   `-- SimplePageAuthorizationStrategy.java
> > |   |-- UnauthorizedActionException.java
> > |   `-- UnauthorizedInstantiationException.java
> >
> >
> > wicket-auth-roles-1.4.12.jar:
> > org.apache
> > `-- wicket
> >|-- authentication
> >|   |-- AuthenticatedWebApplication.java
> >|   |-- AuthenticatedWebSession.java
> >|   |-- pages
> >|   |   |-- SignInPage_fr.html
> >`-- authorization
> >`-- strategies
> >`-- role
> >|-- AbstractRoleAuthorizationStrategy.java
> >|   |-- ActionPermissions.java
> >`-- Roles.java
> >
> > This looks good to OSGi as the classes are in disjoint packages in the
> > two bundles.
> >
> >
> > This changed in 1.5. There the structure looks like this:
> >
> > wicket-1.5-M2.1.jar
> > org.apache
> > `-- wicket
> > |-- authentication
> > |   |-- IAuthenticationStrategy.java
> > |   `-- strategy
> > |   |-- DefaultAuthenticationStrategy.java
> > |   `-- NoOpAuthenticationStrategy.java
> >
> > wicket-auth-roles-1.5-M2.1.jar
> > org.apache
> > `-- wicket
> > |-- authentication
> > |   |-- AuthenticatedWebApplication.java
> > |   |-- AuthenticatedWebSession.java
> > |   |-- pages
> > |   |   |-- SignInPage.html
> > |   |   |-- SignInPage.java
> >
> >
> > The problem is the package org.apache.wicket.authentication now, because
> > the bundle wicket-1.5-M2.1 and wicket-auth-roles-1.5-M2.1 provide
> > classes from this package. The same refers to org.apache.wicket.request,
> > which is exported by wicket-request and wicket in 1.5. This leads to
> > problems in an OSGi environment. OSGi discourages those scenarios, but
> > still offers an solution for this. A (rather old) blog post on osgi.org
> > gives some hints on this:
> >
> > http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html
> >
> > It probably gets to weird loading errors if two classes from the same
> > package want to access each others fields or methods with package access,
> > but come from a different classloader...
> >
> > I'm no OSGi expert, so I don't know the right OSGi header that solves
> > this. Of course, a real solution would be to only have disjoint packages
> > :) I usually put the artifact name in my package name, to avoid any
> > clashes (in fact it makes sense in my module structure).
> >
> >
> > Kind regards,
> > Eike
> >
> >
> > On [Fri, 01.10.2010 10:05], Martin Grigorov wrote:
> > > Hi Elke,
> > >
> > > On Fri, Oct 1, 2010 at 8:34 AM, Eike Kettner  wrote:
> > >
> > > > Hello!
> > > >
> > > > I developed a wicket app using OSGi (felix) where different bundles
> may
> > > > contribute content to the wicket bundle. It works really nice using
> > > > wicket 1.4.9+. Now I want to upgrade to wicket 1.5 and I run in
> problems
> > > > starting the osgi container.
> > > >
> > > > It complains with the good-known classnotfound-exception for classes
> > > > like IClusterabl

Re: Wicket 1.5 and OSGi

[Eike Kettner]

Hi there,

Just a few updates from my side :

I recompiled wicket-trunk with changed a package structure and then my
application starts happily with wicket 1.5-M21. (by the way, I'm using
Apache Felix 3.0.2)

I now use the workaround of wrapping the wicket jars I need into one
jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but
surely not as convienient as before.

Is anybody having these issues with wicket 1.5+OSGi, too? Or even
better, is anybody not having issues with this combination?

Regards,
Eike

On [Fri, 01.10.2010 22:12], Eike Kettner wrote:
> 
> Hello again,
> 
> I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I
> found some differences. For example, wicket 1.5 has a new artifact
> "wicket-request" and comparing the package structure there are some
> changes, which are probably related to my problem:
> 
> wicket-1.4.12.jar:
> org.apache
> `-- wicket
> |-- authorization
> |   |-- Action.java
> |   |-- AuthorizationException.java
> |   |-- strategies
> |   |   |-- action
> |   |   |   |-- ActionAuthorizationStrategy.java
> |   |   |   `-- IActionAuthorizer.java
> |   |   |-- CompoundAuthorizationStrategy.java
> |   |   `-- page
> |   |   |-- AbstractPageAuthorizationStrategy.java
> |   |   `-- SimplePageAuthorizationStrategy.java
> |   |-- UnauthorizedActionException.java
> |   `-- UnauthorizedInstantiationException.java
> 
> 
> wicket-auth-roles-1.4.12.jar:
> org.apache
> `-- wicket
>|-- authentication
>|   |-- AuthenticatedWebApplication.java
>|   |-- AuthenticatedWebSession.java
>|   |-- pages
>|   |   |-- SignInPage_fr.html
>`-- authorization
>`-- strategies
>`-- role
>|-- AbstractRoleAuthorizationStrategy.java
>|   |-- ActionPermissions.java
>`-- Roles.java
> 
> This looks good to OSGi as the classes are in disjoint packages in the
> two bundles.
> 
> 
> This changed in 1.5. There the structure looks like this:
> 
> wicket-1.5-M2.1.jar
> org.apache
> `-- wicket
> |-- authentication
> |   |-- IAuthenticationStrategy.java
> |   `-- strategy
> |   |-- DefaultAuthenticationStrategy.java
> |   `-- NoOpAuthenticationStrategy.java
> 
> wicket-auth-roles-1.5-M2.1.jar
> org.apache
> `-- wicket
> |-- authentication
> |   |-- AuthenticatedWebApplication.java
> |   |-- AuthenticatedWebSession.java
> |   |-- pages
> |   |   |-- SignInPage.html
> |   |   |-- SignInPage.java
> 
> 
> The problem is the package org.apache.wicket.authentication now, because
> the bundle wicket-1.5-M2.1 and wicket-auth-roles-1.5-M2.1 provide
> classes from this package. The same refers to org.apache.wicket.request,
> which is exported by wicket-request and wicket in 1.5. This leads to
> problems in an OSGi environment. OSGi discourages those scenarios, but
> still offers an solution for this. A (rather old) blog post on osgi.org
> gives some hints on this:
> 
> http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html
> 
> It probably gets to weird loading errors if two classes from the same
> package want to access each others fields or methods with package access,
> but come from a different classloader... 
> 
> I'm no OSGi expert, so I don't know the right OSGi header that solves
> this. Of course, a real solution would be to only have disjoint packages
> :) I usually put the artifact name in my package name, to avoid any
> clashes (in fact it makes sense in my module structure).
> 
> 
> Kind regards,
> Eike
> 
> 
> On [Fri, 01.10.2010 10:05], Martin Grigorov wrote:
> > Hi Elke,
> > 
> > On Fri, Oct 1, 2010 at 8:34 AM, Eike Kettner  wrote:
> > 
> > > Hello!
> > >
> > > I developed a wicket app using OSGi (felix) where different bundles may
> > > contribute content to the wicket bundle. It works really nice using
> > > wicket 1.4.9+. Now I want to upgrade to wicket 1.5 and I run in problems
> > > starting the osgi container.
> > >
> > > It complains with the good-known classnotfound-exception for classes
> > > like IClusterable and AuthenticatedWebapplication which all are classes
> > > in packages exported by more than one bundle (for example
> > > org.apache.wicket or org.apache.wicket.authentication). Earlier I found
> > > this was a problem or at least a "not-good" for OSGi bundles. But as am
> > > using OSGi 4.2 this may work with some special treatment (I'v never
> > > tried this though). Do you think I'm doing something wrong or is this
> > > something on the road for 1.5?
> > >
> > I don't have much experience with OSGi so can you give more details what
> > exactly is the problem  ?
> > I think there is no difference in these two classes between 1.4.x and 1.5.x.
> > They are packed the same way.
> > There is no difference in the bnd-maven-plugin configuration as well.
> > If you can find where the problem comes from then we can improve it.
> > 
> > >
> > > Also, since

Re: Wicket 1.4.12 Ajax problems

[Martin Grigorov]

Did you try with 1.4.11 before trying 1.4.12 ?
Someone in IRC had the same problem - try 1.4.11, the browser caches the
broken wicket-ajax.js (see WICKET-3040) and then upgrade to 1.4.12 but the
browser still used the cached version from 1.4.11.

You said that you tried several browsers so maybe it is not the same case.
Many people use 1.4.12 and they don't experience this problem...

On Sun, Oct 3, 2010 at 12:32 PM, Mathias Nilsson <
wicket.program...@gmail.com> wrote:

>
> I also tried 1.4.12 and got the same problem in chrome.
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Wicket-1-4-12-Ajax-problems-tp2930684p2953070.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: Wicket 1.4.12 Ajax problems

[Mathias Nilsson]

I also tried 1.4.12 and got the same problem in chrome.


-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-1-4-12-Ajax-problems-tp2930684p2953070.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: Nested modal windows

[Martin Grigorov]

See http://wicketstuff.org/wicket14/ajax/modal-window , the 'page' example

On Sat, Oct 2, 2010 at 11:55 AM, Chris Colman
wrote:

> I use nested modal windows but I was wondering about how I should set
> those up in markup.
>
> Eg., say I have ModalWindow 0 and Modal Window 1. Modal Window 1 can
> open up on top of Modal Window 0 (nested modal)
>
> Should the markup refelect this nesting or doesn't it matter?
>
> Eg., should the markup be like:
>
> 
>
>
> 
>
> Or is it ok to be:
>
> 
> 
>
>