Re: Pluggable architecture for wicket application

[Decebal Suiu]

You can try wicket-plugin [1].

[1] https://github.com/decebals/wicket-plugin

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Pluggable-architecture-for-wicket-application-tp4676135p4676192.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: Single page app as custom resource?

[Lars Törner]

Interesting! Thank you Andrea!

fre 18 nov. 2016 kl. 12:41 skrev Andrea Del Bene :

> Hi,
>
> I haven't directly tried this approach but there is an Apache project,
> Syncope, that recently has gone in this direction. The following is the
> link to their enduser module which is built with Angular for the
> frontend and uses Wicket resources for the REST API:
>
> https://github.com/apache/syncope/tree/master/client/enduser
>
> On 16/11/2016 12:56, Lars Törner wrote:
> > Ok, thanks Martin!
> >
> > It would be really interesting to hear the opinion of someone that tried
> > the approach.
> >
> > 2016-11-16 12:43 GMT+01:00 Martin Grigorov :
> >
> >> Hi Lars,
> >>
> >> AFAIK some people use this approach in their applications.
> >>
> >> You can use Wicket resources as endpoints or any other, e.g. Spring MVC,
> >> just make sure you "wrap" them in WicketSessionFilter so you have
> access to
> >> Application.get() and Session.get() inside them.
> >>
> >> On Nov 16, 2016 7:41 AM, "Lars Törner"  wrote:
> >>
> >>> Ok, now I found wicketstuff-rest-annotations... so, can I create a
> >> wicket
> >>> page, load resources for a java scriptframework and then use
> >>> wicket-rest-requests with ajax to integrate a SPA in my
> >>> wicket-web-application?
> >>>
> >>> tisdag 15 november 2016 skrev Lars Törner :
> >>>
>  Hi,
> 
>  we're developing a webbapplication to our legacy product and we're
> >> doing
>  it in wicket.
> 
>  We have a few pages which are using a lot of ajax, and therefore each
> >> one
>  of them could be seen as kind of a SPA. (Does that make sense?)
> 
>  Now we might have a case when a client (or we our selves) would like
> to
>  extend the wicket webbapplication with a page/spa written in
> javascript
>  (angular/react etc). From the users point of view, there should be no
>  difference. It should be the same session etc.
> 
>  Can this be done with a dynamic resource? Or in some other way? Is it
> a
>  bad idea or just another way to do things?
> 
>  Cheers
>  Lars
> 
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Single page app as custom resource?

[Andrea Del Bene]

Hi,

I haven't directly tried this approach but there is an Apache project, 
Syncope, that recently has gone in this direction. The following is the 
link to their enduser module which is built with Angular for the 
frontend and uses Wicket resources for the REST API:


https://github.com/apache/syncope/tree/master/client/enduser

On 16/11/2016 12:56, Lars Törner wrote:

Ok, thanks Martin!

It would be really interesting to hear the opinion of someone that tried
the approach.

2016-11-16 12:43 GMT+01:00 Martin Grigorov :


Hi Lars,

AFAIK some people use this approach in their applications.

You can use Wicket resources as endpoints or any other, e.g. Spring MVC,
just make sure you "wrap" them in WicketSessionFilter so you have access to
Application.get() and Session.get() inside them.

On Nov 16, 2016 7:41 AM, "Lars Törner"  wrote:


Ok, now I found wicketstuff-rest-annotations... so, can I create a

wicket

page, load resources for a java scriptframework and then use
wicket-rest-requests with ajax to integrate a SPA in my
wicket-web-application?

tisdag 15 november 2016 skrev Lars Törner :


Hi,

we're developing a webbapplication to our legacy product and we're

doing

it in wicket.

We have a few pages which are using a lot of ajax, and therefore each

one

of them could be seen as kind of a SPA. (Does that make sense?)

Now we might have a case when a client (or we our selves) would like to
extend the wicket webbapplication with a page/spa written in javascript
(angular/react etc). From the users point of view, there should be no
difference. It should be the same session etc.

Can this be done with a dynamic resource? Or in some other way? Is it a
bad idea or just another way to do things?

Cheers
Lars




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

Re: Twitter poll result 2

[Francois Meillet]

Bruno Borges ‏@brunoborges made a Twitter poll by the end of October.

The question was 
If you're a server-side #Java developer building web apps, please respond: have 
you ever tried/used Apache #Wicket?

The final results are (from 1,128 votes) : 

13% Yes, and I like it !
 9% Yes, but just tried
12% Yes, and didn't like
66% No. What is Wicket ?

To all Apache Wicket Users, your contributions to the analysis of these results 
are very important.
Remember any thoughts, any contribution are very welcome !

François


> Le 1 nov. 2016 à 18:11, Mihir Chhaya  a écrit :
> 
> I would like to share my personal experience from developer's perspective.
> First and foremost, I personally love Apache Wicket more than any MVC
> framework I have worked with so far (Struts/JSF). This is just me.
> 
> The place I am currently working adopted Wicket 1.4 around 2012. That time,
> the management in general was relying on individual developer's technical
> skills and abilities. Everybody was recommended to use Wicket 1.4. I
> personally evaluated couple of different options and then picked up Wicket
> 1.4.
> 
> That time, Apache Wicket in general was lacking good documentation, good
> third party libraries and community awareness. Not any more.
> 
> My other colleagues and developers eventually started working with Wicket.
> Many applications got developed using Wicket. Most of the time the code was
> 'copy and paste' from components point of view. We had working components
> developed in-house; but no solid third party components except in-method
> grid (which was great, but with some of the issues of it's own).
> 
> Developers got used to writing Wicket based application.
> 
> Now, agency became more serious on adopting technologies which had sound
> community and commercial technical support, and which could be considered
> as 'standard'. Also, came the need of responsive design and web
> applications for smaller devices.
> 
> More than 75% of the colleagues I was working with were not interested in
> writing their Junit test cases, nor writing their own css/javascript and
> other UI related stuff - I could not find anybody other than 2-3 guys
> interested in developing rich, responsive in-house components. They were
> looking more for ready-to-use components.
> 
> So, the agency started evaluation (close to two years ago) and other
> developers were assigned to find and evaluate different options.
> 
> We had group of developers who had past experience of Richfaces/Icefaces
> etc.
> 
> So, the evaluation started keeping following points in mind:
> 
> 1. Solid technical and commercial support. Larger community support with
> detail documentation.
> 2. Following standards (Java/JEE etc). So if standards changes in future
> then it would be minimal impact.
> 3. Standards supported Out-Of-Box by application servers.
> 4. Responsive design.
> 5. Less of presentation layer coding.
> 6. For CDI/Injections, rely on Java instead of Spring.
> 7. Finding developers with prior experience in specific technology. (This
> is case-by-case and by location. Not necessarily a must - but nice to have
> kind of point to consider in evaluation.)
> 
> And at the end, agency decided to move forward with using JSF (as it is
> 'standard'), EJBs and Java EE based technologies for CDI/Injection.
> Choosing JSF brought Prime-faces and it's theme to develop responsive
> applications for any devices.
> 
> Considering the progress Apache Wicket has made in last couple of years, I
> do believe Apache Wicket can do all of above and much more then any other
> framework. Believe me, I still love Apache Wicket over any other framework.
> It just puts so much of control in my hand instead of relying on some
> bloated versions of html files. Additionally, I am also able to unit test
> and presentation layer - improving my confidence.
> 
> But most of the developers I am working don't care to read and understand
> framework architecture in detail, nor they care exploring the power of such
> frameworks which allows them to build their components the way they want.
> They were primarily looking for something which is ready-to-use (which you
> can get with Apache Wicket + Kendo UI/ BootStrap or any other JS
> framework).
> 
> We do have projects in Wicket (latest one I migrated from 1.4 to Wicket
> 7.1), but all new development is now in JSF.
> 
> Apache Wicket team and the whole community has done exceptionally fantastic
> job in all aspects to improve the framework and making the project more
> appealing.
> 
> Additionally, what can be done to (which Francois has already suggested in
> his post):
> 1. Maximize developers' interest in exploring and looking into the
> components.
> 2. How to show case /sample Wicket based web application developed for
> smaller devices? How to make developers look at Wicket show cases?
> 3. Commercial support and marketing it aggressively.
> 
> By no mean I am trying to show/share that we have migrated