You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by nazeem <md...@gmail.com> on 2012/01/18 08:38:16 UTC
wicket appl architecture
Hi
I am currently developing an application using Wicket + Spring + Hibernate.
So far everything is smooth and I use a lot of Ajax which works perfectly
fine. Now I need to provide options for data entry via mobile devices like
Andriod (Samsing Tab) + iOS (iPad). My initial plan was to develop web
based UI specific to suit these devices so that it reduces the complexity of
developing for multiple platform. But now, I need offline usage as the
signal strength can vary from place to place, so web based option is ruled
out. (not sure if options like gears for offline usage will work in mobile
devices).
Also I need to use device specific native features like camera to upload
photos from the device. So I am planning to develop separate front end for
iOS & Andrioid. Is this the right approach ?
What will be the communication layer between Server & Mobile applications ?
REST ? If not what else. Please suggest.
Also advice on the libraries that will help me get there..
regards,
nazeem
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-appl-architecture-tp4305917p4305917.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket appl architecture
Posted by Arjun Dhar <dh...@yahoo.com>.
JSON Library + CXF wtf!
... This is a pretty good combination thant I've been playing with for over
some time.
-----
Software documentation is like sex: when it is good, it is very, very good; and when it is bad, it is still better than nothing!
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-appl-architecture-tp4305917p4306850.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket appl architecture
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Tue, Jan 24, 2012 at 9:15 PM, Kayode Odeyemi <dr...@gmail.com> wrote:
> On Tue, Jan 24, 2012 at 2:05 AM, nazeem <md...@gmail.com> wrote:
>
>> This is an interesting article referring to the Linked In tech team
>> experience and how they are addressing using client side template..
>>
>>
>> http://blogs.developerforce.com/developer-relations/2011/12/thoughts-on-ui-architectures.html
>> Thoughts on UI Architecture
>>
>>
>> In the above article he refers to this
>>
>> https://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates
>>
>>
>> So, the concept of single json/rest api interface addressing to all type of
>> client (full web based app, mobile version of html app, ios, android, etc).
>> In this case how can I write wicket components to render from jsons ? i
>> believe its not required since its more on the server side, direct pojos
>> should be fine.
>>
>> But at the last he also mentions "Server-side templating should continue to
>> be the default choice for most web applications as it offers many benefits
>> like performance, security etc.".
>> This seemed contradicting to the full details explained.
>>
>> Can any one clarify where does wicket fall in this structure and how we can
>> leverage both (server side templating + client side templating for mobile
>> apps)
>>
>
> +1
>
> Very interesting read. Wicket could be very powerful if components have
> client side templating built in.
Currently Wicket supports generating XML-like responses in non-Ajax requests.
You can do client side templating based on XML - for example .xslt templates.
You can extend Mustache, Dust, Underscore, ... to read the data from
XML instead of JSON and let them do the rest for you.
In Ajax request you can return XML or JSON or any other format data
and render it at the client side with your favorite JS templating
library.
>
> --
> Odeyemi 'Kayode O.
> http://www.sinati.com. t: @charyorde
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket appl architecture
Posted by Kayode Odeyemi <dr...@gmail.com>.
On Tue, Jan 24, 2012 at 2:05 AM, nazeem <md...@gmail.com> wrote:
> This is an interesting article referring to the Linked In tech team
> experience and how they are addressing using client side template..
>
>
> http://blogs.developerforce.com/developer-relations/2011/12/thoughts-on-ui-architectures.html
> Thoughts on UI Architecture
>
>
> In the above article he refers to this
>
> https://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates
>
>
> So, the concept of single json/rest api interface addressing to all type of
> client (full web based app, mobile version of html app, ios, android, etc).
> In this case how can I write wicket components to render from jsons ? i
> believe its not required since its more on the server side, direct pojos
> should be fine.
>
> But at the last he also mentions "Server-side templating should continue to
> be the default choice for most web applications as it offers many benefits
> like performance, security etc.".
> This seemed contradicting to the full details explained.
>
> Can any one clarify where does wicket fall in this structure and how we can
> leverage both (server side templating + client side templating for mobile
> apps)
>
+1
Very interesting read. Wicket could be very powerful if components have
client side templating built in.
--
Odeyemi 'Kayode O.
http://www.sinati.com. t: @charyorde
Re: wicket appl architecture
Posted by nazeem <md...@gmail.com>.
This is an interesting article referring to the Linked In tech team
experience and how they are addressing using client side template..
http://blogs.developerforce.com/developer-relations/2011/12/thoughts-on-ui-architectures.html
Thoughts on UI Architecture
In the above article he refers to this
https://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates
So, the concept of single json/rest api interface addressing to all type of
client (full web based app, mobile version of html app, ios, android, etc).
In this case how can I write wicket components to render from jsons ? i
believe its not required since its more on the server side, direct pojos
should be fine.
But at the last he also mentions "Server-side templating should continue to
be the default choice for most web applications as it offers many benefits
like performance, security etc.".
This seemed contradicting to the full details explained.
Can any one clarify where does wicket fall in this structure and how we can
leverage both (server side templating + client side templating for mobile
apps)
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-appl-architecture-tp4305917p4322698.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket appl architecture
Posted by bh...@gmail.com.
Hi,
I have evaluated SOAP, REST, JSON-RCP architectures and within
multiple implementations in combination with Android.
SOAP(ksoap2) is just too cumbersome and heavy, but probably the only
sensible choice when dealing with legacy services.
REST is fine if you like the architecture of having a separate
endpoint for each resource. Spring REST client with 2MBytes on the
phone it is ten times as large as most other implementations. Try
RESTclient-Android + GSON
https://github.com/TylerSmithNet/RESTclient-Android first.
JSON-RCP provides the most choices, see
http://en.wikipedia.org/wiki/JSON-RPC
However what I found lacking in server implementations is that they
use servlets that have a static reference to a component which does
not work out of the box with pooled resources that you find in
enterprise class containers. http://code.google.com/p/jpoxy/ looks
enticing but look at the Maven debendency graph in NetBeans. No client
implementation so you have to write one yourself. The protocol is not
compatible with other implementations (JSON-RCP does not gurantee
compatibility) and it leaks the fully qualified class name into the
client so you can't re-factor your server class names without breaking
the client code.
Have a look at http://software.dzhuvinov.com/json-rpc-2.0-base.html
and http://code.google.com/p/json-rpc.
A good selection criterion is to check whether the implementations
actually provide both client and server code.
For now I am using http://code.google.com/p/json-rpc
Regards,
Bernard
On Wed, 18 Jan 2012 09:39:28 -0500, you wrote:
>Separate front-end sounds fine. Use a REST architecture with JSON as the
>data exchange format. I'm pretty Spring MVC supports this through the use
>Jackson JSON library. Its something to add to your list of possible options.
>
>
>
>
>On Wed, Jan 18, 2012 at 2:38 AM, nazeem <md...@gmail.com> wrote:
>
>> Hi
>>
>> I am currently developing an application using Wicket + Spring + Hibernate.
>> So far everything is smooth and I use a lot of Ajax which works perfectly
>> fine. Now I need to provide options for data entry via mobile devices like
>> Andriod (Samsing Tab) + iOS (iPad). My initial plan was to develop web
>> based UI specific to suit these devices so that it reduces the complexity
>> of
>> developing for multiple platform. But now, I need offline usage as the
>> signal strength can vary from place to place, so web based option is ruled
>> out. (not sure if options like gears for offline usage will work in mobile
>> devices).
>>
>> Also I need to use device specific native features like camera to upload
>> photos from the device. So I am planning to develop separate front end for
>> iOS & Andrioid. Is this the right approach ?
>>
>> What will be the communication layer between Server & Mobile applications ?
>> REST ? If not what else. Please suggest.
>>
>> Also advice on the libraries that will help me get there..
>>
>> regards,
>> nazeem
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/wicket-appl-architecture-tp4305917p4305917.html
>> Sent from the Users forum mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket appl architecture
Posted by kamiseq <ka...@gmail.com>.
well but then you need to rewrite some logic you already have in
wicket's components, right?
pozdrawiam
Paweł Kamiński
kamiseq@gmail.com
pkaminski.prv@gmail.com
______________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket appl architecture
Posted by Arjun Dhar <dh...@yahoo.com>.
haha .. ur welcome. yes, I meant "ftw = For the Win"; ... well wtf is one for
internet typo humor.
Good luck ;)
-----
Software documentation is like sex: when it is good, it is very, very good; and when it is bad, it is still better than nothing!
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-appl-architecture-tp4305917p4309535.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket appl architecture
Posted by Bas Gooren <ba...@iswd.nl>.
When he wrote "wtf" he probably mean "ftw" (for the win), to indicate
it's a solid combination ;-)
Op 19-1-2012 2:19, schreef nazeem:
> Russell Pitre wrote
>> Separate front-end sounds fine. Use a REST architecture with JSON as the
>> data exchange format. I'm pretty Spring MVC supports this through the use
>> Jackson JSON library. Its something to add to your list of possible
>> options.
>>
> Wicket is component based and differs from Spring MVC. So do you mean you
> are using component based hierarchy for the user interface and spring mvc
> for the REST services exposed for external communication ? Is it possible ?
>
>
> Arjun Dhar wrote
>> JSON Library + CXF wtf!
>>
> Arjun, thank you for the input. Will try CXF, I haven't used it so far.
> Going thru the doc it looks promising with wide support. By the what do you
> mean by wtf! ?
>
>
>
>
>
>
>
>
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-appl-architecture-tp4305917p4308822.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: wicket appl architecture
Posted by nazeem <md...@gmail.com>.
Russell Pitre wrote
>
> Separate front-end sounds fine. Use a REST architecture with JSON as the
> data exchange format. I'm pretty Spring MVC supports this through the use
> Jackson JSON library. Its something to add to your list of possible
> options.
>
Wicket is component based and differs from Spring MVC. So do you mean you
are using component based hierarchy for the user interface and spring mvc
for the REST services exposed for external communication ? Is it possible ?
Arjun Dhar wrote
>
> JSON Library + CXF wtf!
>
Arjun, thank you for the input. Will try CXF, I haven't used it so far.
Going thru the doc it looks promising with wide support. By the what do you
mean by wtf! ?
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-appl-architecture-tp4305917p4308822.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket appl architecture
Posted by Russell Pitre <rp...@gmail.com>.
Separate front-end sounds fine. Use a REST architecture with JSON as the
data exchange format. I'm pretty Spring MVC supports this through the use
Jackson JSON library. Its something to add to your list of possible options.
On Wed, Jan 18, 2012 at 2:38 AM, nazeem <md...@gmail.com> wrote:
> Hi
>
> I am currently developing an application using Wicket + Spring + Hibernate.
> So far everything is smooth and I use a lot of Ajax which works perfectly
> fine. Now I need to provide options for data entry via mobile devices like
> Andriod (Samsing Tab) + iOS (iPad). My initial plan was to develop web
> based UI specific to suit these devices so that it reduces the complexity
> of
> developing for multiple platform. But now, I need offline usage as the
> signal strength can vary from place to place, so web based option is ruled
> out. (not sure if options like gears for offline usage will work in mobile
> devices).
>
> Also I need to use device specific native features like camera to upload
> photos from the device. So I am planning to develop separate front end for
> iOS & Andrioid. Is this the right approach ?
>
> What will be the communication layer between Server & Mobile applications ?
> REST ? If not what else. Please suggest.
>
> Also advice on the libraries that will help me get there..
>
> regards,
> nazeem
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/wicket-appl-architecture-tp4305917p4305917.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>