You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Carlo Camerino <cm...@gmail.com> on 2009/05/01 10:04:58 UTC
Wicket Offline Applications
Hi,
Is there any project which has Wicket And Google Gears Integration?
Wicket has really done a lot of us in speeding up development time. Coming
from a struts we saw the power of Wicket in terms its reusability and i've
noticed that
wicket already did most of the tasks that we would have to manually do using
struts application, like session timeouts, redirects, etc....
One of our main concerns however are that clients
are asking for our applications to be available even if the network is down
or if the central server is down..
Currently we implemented our applications in a distributed fashion wherein
every branch ( Remote Location) has its own server.
However, this has implications of cost and administration issues.
However, if offline mode is enabled we can just begin syncing right.
I think that Wicket WIth Google Gears Application will make it even better .
I think this is really a plus when it comes to marketing it to customers.
Most of the applications that we create our banking applications and any
downtime is costing our clients.
Hopefully we can also do this to offload the central servers and to put
processing into client machines.
One large problem I see though is that most code wil have to be moved to the
Browser Layer.
I'm thinking of how to create a wicket application which is mostly run by
java classes work on the client side.
Looks as if there will be a lot of code changes...
I'm not really sure if it would be a totally different programming model.
Anyone out there tried to integrate Gears And Wicket
Carlo
Re: Wicket Offline Applications
Posted by Jeremy Thomerson <je...@wickettraining.com>.
Gmail uses a fat client - which is what GWT grew out of.
--
Jeremy Thomerson
http://www.wickettraining.com
On Fri, May 1, 2009 at 10:55 AM, Carlo Camerino <cm...@gmail.com> wrote:
> ya i guess they are mostly for rich internet applications use.First thing
> I'd have to work on is to have tight with integration with a specific
> javascript framework.
>
> Wonder how gmail does it.
> Offline gmail simply is the best.
>
> On Fri, May 1, 2009 at 11:39 PM, Ryan Gravener <ry...@ryangravener.com>wrote:
>
>> I would just make an adobe air application for offline use.
>>
>>
>> Ryan Gravener
>> http://isithotinhereorisitjust.me | http://twitter.com/ryangravener
>>
>>
>> On Fri, May 1, 2009 at 10:53 AM, Jeremy Thomerson <
>> jeremy@wickettraining.com
>> > wrote:
>>
>> > I haven't looked into Gears at great length, but I think you may be up
>> > against a wall here - where the two may be incompatible. Offline
>> > gears applications require fat clients. Wicket isn't typically for
>> > making fat clients because everything about it ties it back to the
>> > server.
>> >
>> > If you already have it such that each office has their own server and
>> > database, then it seems that this isn't a product development problem
>> > so much as it's a network support issue. How often should the network
>> > within an office really be down? I'd try to push this problem back up
>> > the management chain.
>> >
>> > Conceptually, it's a cool idea, though. Let us know if you have any
>> > success.
>> >
>> > --
>> > Jeremy Thomerson
>> > http://www.wickettraining.com
>> >
>> >
>> >
>> >
>> > On Fri, May 1, 2009 at 3:04 AM, Carlo Camerino <cm...@gmail.com>
>> > wrote:
>> > > Hi,
>> > >
>> > > Is there any project which has Wicket And Google Gears Integration?
>> > > Wicket has really done a lot of us in speeding up development time.
>> > Coming
>> > > from a struts we saw the power of Wicket in terms its reusability and
>> > i've
>> > > noticed that
>> > > wicket already did most of the tasks that we would have to manually do
>> > using
>> > > struts application, like session timeouts, redirects, etc....
>> > >
>> > > One of our main concerns however are that clients
>> > > are asking for our applications to be available even if the network is
>> > down
>> > > or if the central server is down..
>> > > Currently we implemented our applications in a distributed fashion
>> > wherein
>> > > every branch ( Remote Location) has its own server.
>> > > However, this has implications of cost and administration issues.
>> > > However, if offline mode is enabled we can just begin syncing right.
>> > >
>> > > I think that Wicket WIth Google Gears Application will make it even
>> > better .
>> > >
>> > >
>> > > I think this is really a plus when it comes to marketing it to
>> customers.
>> > > Most of the applications that we create our banking applications and
>> any
>> > > downtime is costing our clients.
>> > >
>> > > Hopefully we can also do this to offload the central servers and to put
>> > > processing into client machines.
>> > >
>> > > One large problem I see though is that most code wil have to be moved
>> to
>> > the
>> > > Browser Layer.
>> > > I'm thinking of how to create a wicket application which is mostly run
>> by
>> > > java classes work on the client side.
>> > > Looks as if there will be a lot of code changes...
>> > > I'm not really sure if it would be a totally different programming
>> model.
>> > >
>> > > Anyone out there tried to integrate Gears And Wicket
>> > >
>> > > Carlo
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > 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 Offline Applications
Posted by Carlo Camerino <cm...@gmail.com>.
ya i guess they are mostly for rich internet applications use.First thing
I'd have to work on is to have tight with integration with a specific
javascript framework.
Wonder how gmail does it.
Offline gmail simply is the best.
On Fri, May 1, 2009 at 11:39 PM, Ryan Gravener <ry...@ryangravener.com>wrote:
> I would just make an adobe air application for offline use.
>
>
> Ryan Gravener
> http://isithotinhereorisitjust.me | http://twitter.com/ryangravener
>
>
> On Fri, May 1, 2009 at 10:53 AM, Jeremy Thomerson <
> jeremy@wickettraining.com
> > wrote:
>
> > I haven't looked into Gears at great length, but I think you may be up
> > against a wall here - where the two may be incompatible. Offline
> > gears applications require fat clients. Wicket isn't typically for
> > making fat clients because everything about it ties it back to the
> > server.
> >
> > If you already have it such that each office has their own server and
> > database, then it seems that this isn't a product development problem
> > so much as it's a network support issue. How often should the network
> > within an office really be down? I'd try to push this problem back up
> > the management chain.
> >
> > Conceptually, it's a cool idea, though. Let us know if you have any
> > success.
> >
> > --
> > Jeremy Thomerson
> > http://www.wickettraining.com
> >
> >
> >
> >
> > On Fri, May 1, 2009 at 3:04 AM, Carlo Camerino <cm...@gmail.com>
> > wrote:
> > > Hi,
> > >
> > > Is there any project which has Wicket And Google Gears Integration?
> > > Wicket has really done a lot of us in speeding up development time.
> > Coming
> > > from a struts we saw the power of Wicket in terms its reusability and
> > i've
> > > noticed that
> > > wicket already did most of the tasks that we would have to manually do
> > using
> > > struts application, like session timeouts, redirects, etc....
> > >
> > > One of our main concerns however are that clients
> > > are asking for our applications to be available even if the network is
> > down
> > > or if the central server is down..
> > > Currently we implemented our applications in a distributed fashion
> > wherein
> > > every branch ( Remote Location) has its own server.
> > > However, this has implications of cost and administration issues.
> > > However, if offline mode is enabled we can just begin syncing right.
> > >
> > > I think that Wicket WIth Google Gears Application will make it even
> > better .
> > >
> > >
> > > I think this is really a plus when it comes to marketing it to
> customers.
> > > Most of the applications that we create our banking applications and
> any
> > > downtime is costing our clients.
> > >
> > > Hopefully we can also do this to offload the central servers and to put
> > > processing into client machines.
> > >
> > > One large problem I see though is that most code wil have to be moved
> to
> > the
> > > Browser Layer.
> > > I'm thinking of how to create a wicket application which is mostly run
> by
> > > java classes work on the client side.
> > > Looks as if there will be a lot of code changes...
> > > I'm not really sure if it would be a totally different programming
> model.
> > >
> > > Anyone out there tried to integrate Gears And Wicket
> > >
> > > Carlo
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: Wicket Offline Applications
Posted by Ryan Gravener <ry...@ryangravener.com>.
I would just make an adobe air application for offline use.
Ryan Gravener
http://isithotinhereorisitjust.me | http://twitter.com/ryangravener
On Fri, May 1, 2009 at 10:53 AM, Jeremy Thomerson <jeremy@wickettraining.com
> wrote:
> I haven't looked into Gears at great length, but I think you may be up
> against a wall here - where the two may be incompatible. Offline
> gears applications require fat clients. Wicket isn't typically for
> making fat clients because everything about it ties it back to the
> server.
>
> If you already have it such that each office has their own server and
> database, then it seems that this isn't a product development problem
> so much as it's a network support issue. How often should the network
> within an office really be down? I'd try to push this problem back up
> the management chain.
>
> Conceptually, it's a cool idea, though. Let us know if you have any
> success.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
>
> On Fri, May 1, 2009 at 3:04 AM, Carlo Camerino <cm...@gmail.com>
> wrote:
> > Hi,
> >
> > Is there any project which has Wicket And Google Gears Integration?
> > Wicket has really done a lot of us in speeding up development time.
> Coming
> > from a struts we saw the power of Wicket in terms its reusability and
> i've
> > noticed that
> > wicket already did most of the tasks that we would have to manually do
> using
> > struts application, like session timeouts, redirects, etc....
> >
> > One of our main concerns however are that clients
> > are asking for our applications to be available even if the network is
> down
> > or if the central server is down..
> > Currently we implemented our applications in a distributed fashion
> wherein
> > every branch ( Remote Location) has its own server.
> > However, this has implications of cost and administration issues.
> > However, if offline mode is enabled we can just begin syncing right.
> >
> > I think that Wicket WIth Google Gears Application will make it even
> better .
> >
> >
> > I think this is really a plus when it comes to marketing it to customers.
> > Most of the applications that we create our banking applications and any
> > downtime is costing our clients.
> >
> > Hopefully we can also do this to offload the central servers and to put
> > processing into client machines.
> >
> > One large problem I see though is that most code wil have to be moved to
> the
> > Browser Layer.
> > I'm thinking of how to create a wicket application which is mostly run by
> > java classes work on the client side.
> > Looks as if there will be a lot of code changes...
> > I'm not really sure if it would be a totally different programming model.
> >
> > Anyone out there tried to integrate Gears And Wicket
> >
> > Carlo
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket Offline Applications
Posted by Jeremy Thomerson <je...@wickettraining.com>.
I haven't looked into Gears at great length, but I think you may be up
against a wall here - where the two may be incompatible. Offline
gears applications require fat clients. Wicket isn't typically for
making fat clients because everything about it ties it back to the
server.
If you already have it such that each office has their own server and
database, then it seems that this isn't a product development problem
so much as it's a network support issue. How often should the network
within an office really be down? I'd try to push this problem back up
the management chain.
Conceptually, it's a cool idea, though. Let us know if you have any success.
--
Jeremy Thomerson
http://www.wickettraining.com
On Fri, May 1, 2009 at 3:04 AM, Carlo Camerino <cm...@gmail.com> wrote:
> Hi,
>
> Is there any project which has Wicket And Google Gears Integration?
> Wicket has really done a lot of us in speeding up development time. Coming
> from a struts we saw the power of Wicket in terms its reusability and i've
> noticed that
> wicket already did most of the tasks that we would have to manually do using
> struts application, like session timeouts, redirects, etc....
>
> One of our main concerns however are that clients
> are asking for our applications to be available even if the network is down
> or if the central server is down..
> Currently we implemented our applications in a distributed fashion wherein
> every branch ( Remote Location) has its own server.
> However, this has implications of cost and administration issues.
> However, if offline mode is enabled we can just begin syncing right.
>
> I think that Wicket WIth Google Gears Application will make it even better .
>
>
> I think this is really a plus when it comes to marketing it to customers.
> Most of the applications that we create our banking applications and any
> downtime is costing our clients.
>
> Hopefully we can also do this to offload the central servers and to put
> processing into client machines.
>
> One large problem I see though is that most code wil have to be moved to the
> Browser Layer.
> I'm thinking of how to create a wicket application which is mostly run by
> java classes work on the client side.
> Looks as if there will be a lot of code changes...
> I'm not really sure if it would be a totally different programming model.
>
> Anyone out there tried to integrate Gears And Wicket
>
> Carlo
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Offline Applications
Posted by taha siddiqi <ta...@gmail.com>.
A popular Indian product FINACLE has an applet which kind of acts as a
fat client and each time a customer detail or scheme detail is fetched
the whole detail gets downloaded into the applet. But it is not an
pure offline application as only the current page can we viewed or
changed and every time you try to commit, it searches for the
network.
May be it helps
taha
On Sun, May 3, 2009 at 10:34 PM, Carlo Camerino <cm...@gmail.com> wrote:
> hmm,
> ya i guess you're right.
> --> further i would look into security of gears, how easy is it for
> --> someone to access the underlying data store?
>
> this will be the major issue.
> sad to say, i don't know how safe is this
> with the branch servers i'm safer.
>
> i don't really know how google gears plays out yet.
> thanks for all the inputs.
>
> On Mon, May 4, 2009 at 12:25 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>
>> you already said each branch has their own server, so why not simply
>> make this server sync to the central server when the connection is
>> available.
>>
>> your argument for administering cost does not make sense as you are
>> heading down the fat client path so instead of having a single server
>> per branch to administer you will have every fat client app instance
>> to administer.
>>
>> further i would look into security of gears, how easy is it for
>> someone to access the underlying data store?
>>
>> -igor
>>
>> On Sun, May 3, 2009 at 4:35 AM, Carlo Camerino <cm...@gmail.com> wrote:
>> > just to add, we don't have any plan of exposing this to the public (retail)
>> > but rather only to people within organization.
>> > so maybe we could have some sort of control.
>> > I don't know the implications of opening offline banking applications to the
>> > public yet :P and i don't really see any usecase for this type of
>> > applications for now.
>> >
>> > btw, it's not that easy to target a larger set of people if you are using
>> > Fat Web clients.
>> > Just my two cents. bandwidht, cpu considerations, etc... maybe it depends on
>> > your geographical location
>> >
>> > On Sun, May 3, 2009 at 7:27 PM, Carlo Camerino <cm...@gmail.com> wrote:
>> >
>> >> There are really a lot of things i have to consider.
>> >> Especially security.
>> >>
>> >> Here Are Some Of The Considerations I Guess
>> >>
>> >> 1.) To View (Subset) Records But Not Edit Or Delete Them
>> >> 2.) Users must not be able to edit reference tables. Tables that are
>> >> referenced by others.
>> >> 3.) Users must be able to enter transactions(Purely Insert,Transaction
>> >> Recording Only) with client side validation and observance of limits and
>> >> rules of course which were defined during online mode. ( Store This Queue
>> >> Somewhere)
>> >>
>> >> I'm not reallyh sure that I want to go through with this however, this is
>> >> just a prototype idea.
>> >>
>> >>
>> >> On Sun, May 3, 2009 at 4:55 PM, Johan Compagner <jc...@gmail.com>wrote:
>> >>
>> >>> I cannot believe that a typical wicket application (and a banking app
>> >>> fall under that category) does well in offline mode, to me offline
>> >>> mode works if the app is just about personal data (like gmail for your
>> >>> email) because if that is not the case and loads of none peronal ==
>> >>> shared data is used, how are you pushing that to the client? Maybe if
>> >>> the data is not thah much (not very likely in a banking app if you
>> >>> ask me) then you can push it to the client. But then when he gets
>> >>> online again you have to merge everything and resolve conflicts in the
>> >>> data...
>> >>>
>> >>> But wicket doesnt really play well for this at all. GWT or just
>> >>> another fat client like air or just java webstart would be better
>> >>>
>> >>> On 03/05/2009, Carlo Camerino <cm...@gmail.com> wrote:
>> >>> > hmm, you have a point here.however, every requirement is different.
>> >>> >
>> >>> > I know that it may sound weird, but still I believe that it depends on
>> >>> the
>> >>> > nature of the application.
>> >>> > There are lots of types of applications that banks use.
>> >>> > Some I know would have to always have a central server managing it.
>> >>> >
>> >>> > There are different types of Technical Architectures that we cater for
>> >>> in
>> >>> > our applications.
>> >>> > There are some applicationms that always require online mode regardless
>> >>> adn
>> >>> > there are applications that the user just
>> >>> > needs to be able to view customer information ,etc....
>> >>> >
>> >>> >
>> >>> > actually it's hard to decide here.
>> >>> > on the downside, I heard that GWT consumes a lot of resources on the
>> >>> client
>> >>> > side, it's also a consideration.
>> >>> >
>> >>> > Failsafe servers are of course an option but again, the network is still
>> >>> a
>> >>> > factor here.
>> >>> > For example a very slow connection to the central server makes my
>> >>> > productivity a lot less.
>> >>> > Some places suffer from low bandwidth, unreliable networks, etc...
>> >>> >
>> >>> > I saw the value of distributed or offline applications that uses
>> >>> > synchronization.
>> >>> > It will be harder for the developers of course sicne they have to cater
>> >>> to
>> >>> > two modes.
>> >>> > On Sun, May 3, 2009 at 1:55 PM, Vladimir K <ko...@gmail.com> wrote:
>> >>> >
>> >>> >>
>> >>> >> I would install failsafe cluster rather satisfying every client request
>> >>> >> about
>> >>> >> offline workability. You may end up implementing all the front-end and
>> >>> >> middle-end features in offline mode :)
>> >>> >>
>> >>> >> I believe offline mode should be used with care. The email applications
>> >>> >> are
>> >>> >> by nature offline. If you are certain that what the user does is
>> >>> offline
>> >>> >> by
>> >>> >> nature - implement it. If you have concerns that it should be involved
>> >>> >> into
>> >>> >> transaction (I mean a bit wider meaning than DB transaction) -
>> >>> implement
>> >>> >> it
>> >>> >> online and think about fail-safe servers.
>> >>> >>
>> >>> >> Concerning front-end and middle-end, AFAIK, every unit of work is a
>> >>> >> transaction which is done with multi-level authorization, including
>> >>> >> business
>> >>> >> authorization. You either implement all the authorization offline
>> >>> >> (insecure
>> >>> >> at all, and impossible in some cases) or defer authorization untill
>> >>> online
>> >>> >> mode (non-transactional). If a request of some client was satisfied (in
>> >>> >> offline mode) and then hasn't passed online authorization (for instance
>> >>> it
>> >>> >> violates some limits which can be thruly calculated on the server side
>> >>> >> only), you will have to call the client and tell him your appologises
>> >>> (or
>> >>> >> not directly you, then the bank. but the bank will then call you and
>> >>> tell
>> >>> >> you something awesome).
>> >>> >>
>> >>> >> Or just tell me the name of the bank. I will never become its client :)
>> >>> >>
>> >>> >>
>> >>> >> Carlo Camerino wrote:
>> >>> >> >
>> >>> >> > it's not for the public to use. but rather for people within the
>> >>> banks.
>> >>> >> > internal applications. sometimes central connection is not available.
>> >>> >> >
>> >>> >> > On Fri, May 1, 2009 at 9:37 PM, James Carman
>> >>> >> > <jc...@carmanconsulting.com>wrote:
>> >>> >> >
>> >>> >> >> Are you sure a banking application would be the right place for a
>> >>> >> >> gears-based implementation? Wouldn't it be kinda important to make
>> >>> >> >> sure the main server knows where everything is, when money is
>> >>> >> >> concerned?
>> >>> >> >>
>> >>> >> >> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino <
>> >>> cmcamerino@gmail.com>
>> >>> >> >> wrote:
>> >>> >> >> > Hi,
>> >>> >> >> >
>> >>> >> >> > Is there any project which has Wicket And Google Gears
>> >>> Integration?
>> >>> >> >> > Wicket has really done a lot of us in speeding up development
>> >>> time.
>> >>> >> >> Coming
>> >>> >> >> > from a struts we saw the power of Wicket in terms its reusability
>> >>> and
>> >>> >> >> i've
>> >>> >> >> > noticed that
>> >>> >> >> > wicket already did most of the tasks that we would have to
>> >>> manually
>> >>> >> >> > do
>> >>> >> >> using
>> >>> >> >> > struts application, like session timeouts, redirects, etc....
>> >>> >> >> >
>> >>> >> >> > One of our main concerns however are that clients
>> >>> >> >> > are asking for our applications to be available even if the
>> >>> network
>> >>> >> >> > is
>> >>> >> >> down
>> >>> >> >> > or if the central server is down..
>> >>> >> >> > Currently we implemented our applications in a distributed fashion
>> >>> >> >> wherein
>> >>> >> >> > every branch ( Remote Location) has its own server.
>> >>> >> >> > However, this has implications of cost and administration issues.
>> >>> >> >> > However, if offline mode is enabled we can just begin syncing
>> >>> right.
>> >>> >> >> >
>> >>> >> >> > I think that Wicket WIth Google Gears Application will make it
>> >>> even
>> >>> >> >> better .
>> >>> >> >> >
>> >>> >> >> >
>> >>> >> >> > I think this is really a plus when it comes to marketing it to
>> >>> >> >> customers.
>> >>> >> >> > Most of the applications that we create our banking applications
>> >>> and
>> >>> >> >> any
>> >>> >> >> > downtime is costing our clients.
>> >>> >> >> >
>> >>> >> >> > Hopefully we can also do this to offload the central servers and
>> >>> to
>> >>> >> put
>> >>> >> >> > processing into client machines.
>> >>> >> >> >
>> >>> >> >> > One large problem I see though is that most code wil have to be
>> >>> moved
>> >>> >> >> to
>> >>> >> >> the
>> >>> >> >> > Browser Layer.
>> >>> >> >> > I'm thinking of how to create a wicket application which is mostly
>> >>> >> >> > run
>> >>> >> >> by
>> >>> >> >> > java classes work on the client side.
>> >>> >> >> > Looks as if there will be a lot of code changes...
>> >>> >> >> > I'm not really sure if it would be a totally different programming
>> >>> >> >> model.
>> >>> >> >> >
>> >>> >> >> > Anyone out there tried to integrate Gears And Wicket
>> >>> >> >> >
>> >>> >> >> > Carlo
>> >>> >> >> >
>> >>> >> >>
>> >>> >> >>
>> >>> ---------------------------------------------------------------------
>> >>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>> >> >>
>> >>> >> >>
>> >>> >> >
>> >>> >> >
>> >>> >>
>> >>> >> --
>> >>> >> View this message in context:
>> >>> >>
>> >>> http://www.nabble.com/Wicket-Offline-Applications-tp23329675p23352910.html
>> >>> >> Sent from the Wicket - User 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
>> >>>
>> >>>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Offline Applications
Posted by Carlo Camerino <cm...@gmail.com>.
hmm,
ya i guess you're right.
--> further i would look into security of gears, how easy is it for
--> someone to access the underlying data store?
this will be the major issue.
sad to say, i don't know how safe is this
with the branch servers i'm safer.
i don't really know how google gears plays out yet.
thanks for all the inputs.
On Mon, May 4, 2009 at 12:25 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>
> you already said each branch has their own server, so why not simply
> make this server sync to the central server when the connection is
> available.
>
> your argument for administering cost does not make sense as you are
> heading down the fat client path so instead of having a single server
> per branch to administer you will have every fat client app instance
> to administer.
>
> further i would look into security of gears, how easy is it for
> someone to access the underlying data store?
>
> -igor
>
> On Sun, May 3, 2009 at 4:35 AM, Carlo Camerino <cm...@gmail.com> wrote:
> > just to add, we don't have any plan of exposing this to the public (retail)
> > but rather only to people within organization.
> > so maybe we could have some sort of control.
> > I don't know the implications of opening offline banking applications to the
> > public yet :P and i don't really see any usecase for this type of
> > applications for now.
> >
> > btw, it's not that easy to target a larger set of people if you are using
> > Fat Web clients.
> > Just my two cents. bandwidht, cpu considerations, etc... maybe it depends on
> > your geographical location
> >
> > On Sun, May 3, 2009 at 7:27 PM, Carlo Camerino <cm...@gmail.com> wrote:
> >
> >> There are really a lot of things i have to consider.
> >> Especially security.
> >>
> >> Here Are Some Of The Considerations I Guess
> >>
> >> 1.) To View (Subset) Records But Not Edit Or Delete Them
> >> 2.) Users must not be able to edit reference tables. Tables that are
> >> referenced by others.
> >> 3.) Users must be able to enter transactions(Purely Insert,Transaction
> >> Recording Only) with client side validation and observance of limits and
> >> rules of course which were defined during online mode. ( Store This Queue
> >> Somewhere)
> >>
> >> I'm not reallyh sure that I want to go through with this however, this is
> >> just a prototype idea.
> >>
> >>
> >> On Sun, May 3, 2009 at 4:55 PM, Johan Compagner <jc...@gmail.com>wrote:
> >>
> >>> I cannot believe that a typical wicket application (and a banking app
> >>> fall under that category) does well in offline mode, to me offline
> >>> mode works if the app is just about personal data (like gmail for your
> >>> email) because if that is not the case and loads of none peronal ==
> >>> shared data is used, how are you pushing that to the client? Maybe if
> >>> the data is not thah much (not very likely in a banking app if you
> >>> ask me) then you can push it to the client. But then when he gets
> >>> online again you have to merge everything and resolve conflicts in the
> >>> data...
> >>>
> >>> But wicket doesnt really play well for this at all. GWT or just
> >>> another fat client like air or just java webstart would be better
> >>>
> >>> On 03/05/2009, Carlo Camerino <cm...@gmail.com> wrote:
> >>> > hmm, you have a point here.however, every requirement is different.
> >>> >
> >>> > I know that it may sound weird, but still I believe that it depends on
> >>> the
> >>> > nature of the application.
> >>> > There are lots of types of applications that banks use.
> >>> > Some I know would have to always have a central server managing it.
> >>> >
> >>> > There are different types of Technical Architectures that we cater for
> >>> in
> >>> > our applications.
> >>> > There are some applicationms that always require online mode regardless
> >>> adn
> >>> > there are applications that the user just
> >>> > needs to be able to view customer information ,etc....
> >>> >
> >>> >
> >>> > actually it's hard to decide here.
> >>> > on the downside, I heard that GWT consumes a lot of resources on the
> >>> client
> >>> > side, it's also a consideration.
> >>> >
> >>> > Failsafe servers are of course an option but again, the network is still
> >>> a
> >>> > factor here.
> >>> > For example a very slow connection to the central server makes my
> >>> > productivity a lot less.
> >>> > Some places suffer from low bandwidth, unreliable networks, etc...
> >>> >
> >>> > I saw the value of distributed or offline applications that uses
> >>> > synchronization.
> >>> > It will be harder for the developers of course sicne they have to cater
> >>> to
> >>> > two modes.
> >>> > On Sun, May 3, 2009 at 1:55 PM, Vladimir K <ko...@gmail.com> wrote:
> >>> >
> >>> >>
> >>> >> I would install failsafe cluster rather satisfying every client request
> >>> >> about
> >>> >> offline workability. You may end up implementing all the front-end and
> >>> >> middle-end features in offline mode :)
> >>> >>
> >>> >> I believe offline mode should be used with care. The email applications
> >>> >> are
> >>> >> by nature offline. If you are certain that what the user does is
> >>> offline
> >>> >> by
> >>> >> nature - implement it. If you have concerns that it should be involved
> >>> >> into
> >>> >> transaction (I mean a bit wider meaning than DB transaction) -
> >>> implement
> >>> >> it
> >>> >> online and think about fail-safe servers.
> >>> >>
> >>> >> Concerning front-end and middle-end, AFAIK, every unit of work is a
> >>> >> transaction which is done with multi-level authorization, including
> >>> >> business
> >>> >> authorization. You either implement all the authorization offline
> >>> >> (insecure
> >>> >> at all, and impossible in some cases) or defer authorization untill
> >>> online
> >>> >> mode (non-transactional). If a request of some client was satisfied (in
> >>> >> offline mode) and then hasn't passed online authorization (for instance
> >>> it
> >>> >> violates some limits which can be thruly calculated on the server side
> >>> >> only), you will have to call the client and tell him your appologises
> >>> (or
> >>> >> not directly you, then the bank. but the bank will then call you and
> >>> tell
> >>> >> you something awesome).
> >>> >>
> >>> >> Or just tell me the name of the bank. I will never become its client :)
> >>> >>
> >>> >>
> >>> >> Carlo Camerino wrote:
> >>> >> >
> >>> >> > it's not for the public to use. but rather for people within the
> >>> banks.
> >>> >> > internal applications. sometimes central connection is not available.
> >>> >> >
> >>> >> > On Fri, May 1, 2009 at 9:37 PM, James Carman
> >>> >> > <jc...@carmanconsulting.com>wrote:
> >>> >> >
> >>> >> >> Are you sure a banking application would be the right place for a
> >>> >> >> gears-based implementation? Wouldn't it be kinda important to make
> >>> >> >> sure the main server knows where everything is, when money is
> >>> >> >> concerned?
> >>> >> >>
> >>> >> >> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino <
> >>> cmcamerino@gmail.com>
> >>> >> >> wrote:
> >>> >> >> > Hi,
> >>> >> >> >
> >>> >> >> > Is there any project which has Wicket And Google Gears
> >>> Integration?
> >>> >> >> > Wicket has really done a lot of us in speeding up development
> >>> time.
> >>> >> >> Coming
> >>> >> >> > from a struts we saw the power of Wicket in terms its reusability
> >>> and
> >>> >> >> i've
> >>> >> >> > noticed that
> >>> >> >> > wicket already did most of the tasks that we would have to
> >>> manually
> >>> >> >> > do
> >>> >> >> using
> >>> >> >> > struts application, like session timeouts, redirects, etc....
> >>> >> >> >
> >>> >> >> > One of our main concerns however are that clients
> >>> >> >> > are asking for our applications to be available even if the
> >>> network
> >>> >> >> > is
> >>> >> >> down
> >>> >> >> > or if the central server is down..
> >>> >> >> > Currently we implemented our applications in a distributed fashion
> >>> >> >> wherein
> >>> >> >> > every branch ( Remote Location) has its own server.
> >>> >> >> > However, this has implications of cost and administration issues.
> >>> >> >> > However, if offline mode is enabled we can just begin syncing
> >>> right.
> >>> >> >> >
> >>> >> >> > I think that Wicket WIth Google Gears Application will make it
> >>> even
> >>> >> >> better .
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > I think this is really a plus when it comes to marketing it to
> >>> >> >> customers.
> >>> >> >> > Most of the applications that we create our banking applications
> >>> and
> >>> >> >> any
> >>> >> >> > downtime is costing our clients.
> >>> >> >> >
> >>> >> >> > Hopefully we can also do this to offload the central servers and
> >>> to
> >>> >> put
> >>> >> >> > processing into client machines.
> >>> >> >> >
> >>> >> >> > One large problem I see though is that most code wil have to be
> >>> moved
> >>> >> >> to
> >>> >> >> the
> >>> >> >> > Browser Layer.
> >>> >> >> > I'm thinking of how to create a wicket application which is mostly
> >>> >> >> > run
> >>> >> >> by
> >>> >> >> > java classes work on the client side.
> >>> >> >> > Looks as if there will be a lot of code changes...
> >>> >> >> > I'm not really sure if it would be a totally different programming
> >>> >> >> model.
> >>> >> >> >
> >>> >> >> > Anyone out there tried to integrate Gears And Wicket
> >>> >> >> >
> >>> >> >> > Carlo
> >>> >> >> >
> >>> >> >>
> >>> >> >>
> >>> ---------------------------------------------------------------------
> >>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>> >> >>
> >>> >> >>
> >>> >> >
> >>> >> >
> >>> >>
> >>> >> --
> >>> >> View this message in context:
> >>> >>
> >>> http://www.nabble.com/Wicket-Offline-Applications-tp23329675p23352910.html
> >>> >> Sent from the Wicket - User 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
> >>>
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> 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 Offline Applications
Posted by Igor Vaynberg <ig...@gmail.com>.
you already said each branch has their own server, so why not simply
make this server sync to the central server when the connection is
available.
your argument for administering cost does not make sense as you are
heading down the fat client path so instead of having a single server
per branch to administer you will have every fat client app instance
to administer.
further i would look into security of gears, how easy is it for
someone to access the underlying data store?
-igor
On Sun, May 3, 2009 at 4:35 AM, Carlo Camerino <cm...@gmail.com> wrote:
> just to add, we don't have any plan of exposing this to the public (retail)
> but rather only to people within organization.
> so maybe we could have some sort of control.
> I don't know the implications of opening offline banking applications to the
> public yet :P and i don't really see any usecase for this type of
> applications for now.
>
> btw, it's not that easy to target a larger set of people if you are using
> Fat Web clients.
> Just my two cents. bandwidht, cpu considerations, etc... maybe it depends on
> your geographical location
>
> On Sun, May 3, 2009 at 7:27 PM, Carlo Camerino <cm...@gmail.com> wrote:
>
>> There are really a lot of things i have to consider.
>> Especially security.
>>
>> Here Are Some Of The Considerations I Guess
>>
>> 1.) To View (Subset) Records But Not Edit Or Delete Them
>> 2.) Users must not be able to edit reference tables. Tables that are
>> referenced by others.
>> 3.) Users must be able to enter transactions(Purely Insert,Transaction
>> Recording Only) with client side validation and observance of limits and
>> rules of course which were defined during online mode. ( Store This Queue
>> Somewhere)
>>
>> I'm not reallyh sure that I want to go through with this however, this is
>> just a prototype idea.
>>
>>
>> On Sun, May 3, 2009 at 4:55 PM, Johan Compagner <jc...@gmail.com>wrote:
>>
>>> I cannot believe that a typical wicket application (and a banking app
>>> fall under that category) does well in offline mode, to me offline
>>> mode works if the app is just about personal data (like gmail for your
>>> email) because if that is not the case and loads of none peronal ==
>>> shared data is used, how are you pushing that to the client? Maybe if
>>> the data is not thah much (not very likely in a banking app if you
>>> ask me) then you can push it to the client. But then when he gets
>>> online again you have to merge everything and resolve conflicts in the
>>> data...
>>>
>>> But wicket doesnt really play well for this at all. GWT or just
>>> another fat client like air or just java webstart would be better
>>>
>>> On 03/05/2009, Carlo Camerino <cm...@gmail.com> wrote:
>>> > hmm, you have a point here.however, every requirement is different.
>>> >
>>> > I know that it may sound weird, but still I believe that it depends on
>>> the
>>> > nature of the application.
>>> > There are lots of types of applications that banks use.
>>> > Some I know would have to always have a central server managing it.
>>> >
>>> > There are different types of Technical Architectures that we cater for
>>> in
>>> > our applications.
>>> > There are some applicationms that always require online mode regardless
>>> adn
>>> > there are applications that the user just
>>> > needs to be able to view customer information ,etc....
>>> >
>>> >
>>> > actually it's hard to decide here.
>>> > on the downside, I heard that GWT consumes a lot of resources on the
>>> client
>>> > side, it's also a consideration.
>>> >
>>> > Failsafe servers are of course an option but again, the network is still
>>> a
>>> > factor here.
>>> > For example a very slow connection to the central server makes my
>>> > productivity a lot less.
>>> > Some places suffer from low bandwidth, unreliable networks, etc...
>>> >
>>> > I saw the value of distributed or offline applications that uses
>>> > synchronization.
>>> > It will be harder for the developers of course sicne they have to cater
>>> to
>>> > two modes.
>>> > On Sun, May 3, 2009 at 1:55 PM, Vladimir K <ko...@gmail.com> wrote:
>>> >
>>> >>
>>> >> I would install failsafe cluster rather satisfying every client request
>>> >> about
>>> >> offline workability. You may end up implementing all the front-end and
>>> >> middle-end features in offline mode :)
>>> >>
>>> >> I believe offline mode should be used with care. The email applications
>>> >> are
>>> >> by nature offline. If you are certain that what the user does is
>>> offline
>>> >> by
>>> >> nature - implement it. If you have concerns that it should be involved
>>> >> into
>>> >> transaction (I mean a bit wider meaning than DB transaction) -
>>> implement
>>> >> it
>>> >> online and think about fail-safe servers.
>>> >>
>>> >> Concerning front-end and middle-end, AFAIK, every unit of work is a
>>> >> transaction which is done with multi-level authorization, including
>>> >> business
>>> >> authorization. You either implement all the authorization offline
>>> >> (insecure
>>> >> at all, and impossible in some cases) or defer authorization untill
>>> online
>>> >> mode (non-transactional). If a request of some client was satisfied (in
>>> >> offline mode) and then hasn't passed online authorization (for instance
>>> it
>>> >> violates some limits which can be thruly calculated on the server side
>>> >> only), you will have to call the client and tell him your appologises
>>> (or
>>> >> not directly you, then the bank. but the bank will then call you and
>>> tell
>>> >> you something awesome).
>>> >>
>>> >> Or just tell me the name of the bank. I will never become its client :)
>>> >>
>>> >>
>>> >> Carlo Camerino wrote:
>>> >> >
>>> >> > it's not for the public to use. but rather for people within the
>>> banks.
>>> >> > internal applications. sometimes central connection is not available.
>>> >> >
>>> >> > On Fri, May 1, 2009 at 9:37 PM, James Carman
>>> >> > <jc...@carmanconsulting.com>wrote:
>>> >> >
>>> >> >> Are you sure a banking application would be the right place for a
>>> >> >> gears-based implementation? Wouldn't it be kinda important to make
>>> >> >> sure the main server knows where everything is, when money is
>>> >> >> concerned?
>>> >> >>
>>> >> >> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino <
>>> cmcamerino@gmail.com>
>>> >> >> wrote:
>>> >> >> > Hi,
>>> >> >> >
>>> >> >> > Is there any project which has Wicket And Google Gears
>>> Integration?
>>> >> >> > Wicket has really done a lot of us in speeding up development
>>> time.
>>> >> >> Coming
>>> >> >> > from a struts we saw the power of Wicket in terms its reusability
>>> and
>>> >> >> i've
>>> >> >> > noticed that
>>> >> >> > wicket already did most of the tasks that we would have to
>>> manually
>>> >> >> > do
>>> >> >> using
>>> >> >> > struts application, like session timeouts, redirects, etc....
>>> >> >> >
>>> >> >> > One of our main concerns however are that clients
>>> >> >> > are asking for our applications to be available even if the
>>> network
>>> >> >> > is
>>> >> >> down
>>> >> >> > or if the central server is down..
>>> >> >> > Currently we implemented our applications in a distributed fashion
>>> >> >> wherein
>>> >> >> > every branch ( Remote Location) has its own server.
>>> >> >> > However, this has implications of cost and administration issues.
>>> >> >> > However, if offline mode is enabled we can just begin syncing
>>> right.
>>> >> >> >
>>> >> >> > I think that Wicket WIth Google Gears Application will make it
>>> even
>>> >> >> better .
>>> >> >> >
>>> >> >> >
>>> >> >> > I think this is really a plus when it comes to marketing it to
>>> >> >> customers.
>>> >> >> > Most of the applications that we create our banking applications
>>> and
>>> >> >> any
>>> >> >> > downtime is costing our clients.
>>> >> >> >
>>> >> >> > Hopefully we can also do this to offload the central servers and
>>> to
>>> >> put
>>> >> >> > processing into client machines.
>>> >> >> >
>>> >> >> > One large problem I see though is that most code wil have to be
>>> moved
>>> >> >> to
>>> >> >> the
>>> >> >> > Browser Layer.
>>> >> >> > I'm thinking of how to create a wicket application which is mostly
>>> >> >> > run
>>> >> >> by
>>> >> >> > java classes work on the client side.
>>> >> >> > Looks as if there will be a lot of code changes...
>>> >> >> > I'm not really sure if it would be a totally different programming
>>> >> >> model.
>>> >> >> >
>>> >> >> > Anyone out there tried to integrate Gears And Wicket
>>> >> >> >
>>> >> >> > Carlo
>>> >> >> >
>>> >> >>
>>> >> >>
>>> ---------------------------------------------------------------------
>>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >> --
>>> >> View this message in context:
>>> >>
>>> http://www.nabble.com/Wicket-Offline-Applications-tp23329675p23352910.html
>>> >> Sent from the Wicket - User 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
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Offline Applications
Posted by Carlo Camerino <cm...@gmail.com>.
just to add, we don't have any plan of exposing this to the public (retail)
but rather only to people within organization.
so maybe we could have some sort of control.
I don't know the implications of opening offline banking applications to the
public yet :P and i don't really see any usecase for this type of
applications for now.
btw, it's not that easy to target a larger set of people if you are using
Fat Web clients.
Just my two cents. bandwidht, cpu considerations, etc... maybe it depends on
your geographical location
On Sun, May 3, 2009 at 7:27 PM, Carlo Camerino <cm...@gmail.com> wrote:
> There are really a lot of things i have to consider.
> Especially security.
>
> Here Are Some Of The Considerations I Guess
>
> 1.) To View (Subset) Records But Not Edit Or Delete Them
> 2.) Users must not be able to edit reference tables. Tables that are
> referenced by others.
> 3.) Users must be able to enter transactions(Purely Insert,Transaction
> Recording Only) with client side validation and observance of limits and
> rules of course which were defined during online mode. ( Store This Queue
> Somewhere)
>
> I'm not reallyh sure that I want to go through with this however, this is
> just a prototype idea.
>
>
> On Sun, May 3, 2009 at 4:55 PM, Johan Compagner <jc...@gmail.com>wrote:
>
>> I cannot believe that a typical wicket application (and a banking app
>> fall under that category) does well in offline mode, to me offline
>> mode works if the app is just about personal data (like gmail for your
>> email) because if that is not the case and loads of none peronal ==
>> shared data is used, how are you pushing that to the client? Maybe if
>> the data is not thah much (not very likely in a banking app if you
>> ask me) then you can push it to the client. But then when he gets
>> online again you have to merge everything and resolve conflicts in the
>> data...
>>
>> But wicket doesnt really play well for this at all. GWT or just
>> another fat client like air or just java webstart would be better
>>
>> On 03/05/2009, Carlo Camerino <cm...@gmail.com> wrote:
>> > hmm, you have a point here.however, every requirement is different.
>> >
>> > I know that it may sound weird, but still I believe that it depends on
>> the
>> > nature of the application.
>> > There are lots of types of applications that banks use.
>> > Some I know would have to always have a central server managing it.
>> >
>> > There are different types of Technical Architectures that we cater for
>> in
>> > our applications.
>> > There are some applicationms that always require online mode regardless
>> adn
>> > there are applications that the user just
>> > needs to be able to view customer information ,etc....
>> >
>> >
>> > actually it's hard to decide here.
>> > on the downside, I heard that GWT consumes a lot of resources on the
>> client
>> > side, it's also a consideration.
>> >
>> > Failsafe servers are of course an option but again, the network is still
>> a
>> > factor here.
>> > For example a very slow connection to the central server makes my
>> > productivity a lot less.
>> > Some places suffer from low bandwidth, unreliable networks, etc...
>> >
>> > I saw the value of distributed or offline applications that uses
>> > synchronization.
>> > It will be harder for the developers of course sicne they have to cater
>> to
>> > two modes.
>> > On Sun, May 3, 2009 at 1:55 PM, Vladimir K <ko...@gmail.com> wrote:
>> >
>> >>
>> >> I would install failsafe cluster rather satisfying every client request
>> >> about
>> >> offline workability. You may end up implementing all the front-end and
>> >> middle-end features in offline mode :)
>> >>
>> >> I believe offline mode should be used with care. The email applications
>> >> are
>> >> by nature offline. If you are certain that what the user does is
>> offline
>> >> by
>> >> nature - implement it. If you have concerns that it should be involved
>> >> into
>> >> transaction (I mean a bit wider meaning than DB transaction) -
>> implement
>> >> it
>> >> online and think about fail-safe servers.
>> >>
>> >> Concerning front-end and middle-end, AFAIK, every unit of work is a
>> >> transaction which is done with multi-level authorization, including
>> >> business
>> >> authorization. You either implement all the authorization offline
>> >> (insecure
>> >> at all, and impossible in some cases) or defer authorization untill
>> online
>> >> mode (non-transactional). If a request of some client was satisfied (in
>> >> offline mode) and then hasn't passed online authorization (for instance
>> it
>> >> violates some limits which can be thruly calculated on the server side
>> >> only), you will have to call the client and tell him your appologises
>> (or
>> >> not directly you, then the bank. but the bank will then call you and
>> tell
>> >> you something awesome).
>> >>
>> >> Or just tell me the name of the bank. I will never become its client :)
>> >>
>> >>
>> >> Carlo Camerino wrote:
>> >> >
>> >> > it's not for the public to use. but rather for people within the
>> banks.
>> >> > internal applications. sometimes central connection is not available.
>> >> >
>> >> > On Fri, May 1, 2009 at 9:37 PM, James Carman
>> >> > <jc...@carmanconsulting.com>wrote:
>> >> >
>> >> >> Are you sure a banking application would be the right place for a
>> >> >> gears-based implementation? Wouldn't it be kinda important to make
>> >> >> sure the main server knows where everything is, when money is
>> >> >> concerned?
>> >> >>
>> >> >> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino <
>> cmcamerino@gmail.com>
>> >> >> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > Is there any project which has Wicket And Google Gears
>> Integration?
>> >> >> > Wicket has really done a lot of us in speeding up development
>> time.
>> >> >> Coming
>> >> >> > from a struts we saw the power of Wicket in terms its reusability
>> and
>> >> >> i've
>> >> >> > noticed that
>> >> >> > wicket already did most of the tasks that we would have to
>> manually
>> >> >> > do
>> >> >> using
>> >> >> > struts application, like session timeouts, redirects, etc....
>> >> >> >
>> >> >> > One of our main concerns however are that clients
>> >> >> > are asking for our applications to be available even if the
>> network
>> >> >> > is
>> >> >> down
>> >> >> > or if the central server is down..
>> >> >> > Currently we implemented our applications in a distributed fashion
>> >> >> wherein
>> >> >> > every branch ( Remote Location) has its own server.
>> >> >> > However, this has implications of cost and administration issues.
>> >> >> > However, if offline mode is enabled we can just begin syncing
>> right.
>> >> >> >
>> >> >> > I think that Wicket WIth Google Gears Application will make it
>> even
>> >> >> better .
>> >> >> >
>> >> >> >
>> >> >> > I think this is really a plus when it comes to marketing it to
>> >> >> customers.
>> >> >> > Most of the applications that we create our banking applications
>> and
>> >> >> any
>> >> >> > downtime is costing our clients.
>> >> >> >
>> >> >> > Hopefully we can also do this to offload the central servers and
>> to
>> >> put
>> >> >> > processing into client machines.
>> >> >> >
>> >> >> > One large problem I see though is that most code wil have to be
>> moved
>> >> >> to
>> >> >> the
>> >> >> > Browser Layer.
>> >> >> > I'm thinking of how to create a wicket application which is mostly
>> >> >> > run
>> >> >> by
>> >> >> > java classes work on the client side.
>> >> >> > Looks as if there will be a lot of code changes...
>> >> >> > I'm not really sure if it would be a totally different programming
>> >> >> model.
>> >> >> >
>> >> >> > Anyone out there tried to integrate Gears And Wicket
>> >> >> >
>> >> >> > Carlo
>> >> >> >
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Wicket-Offline-Applications-tp23329675p23352910.html
>> >> Sent from the Wicket - User 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 Offline Applications
Posted by Carlo Camerino <cm...@gmail.com>.
There are really a lot of things i have to consider.
Especially security.
Here Are Some Of The Considerations I Guess
1.) To View (Subset) Records But Not Edit Or Delete Them
2.) Users must not be able to edit reference tables. Tables that are
referenced by others.
3.) Users must be able to enter transactions(Purely Insert,Transaction
Recording Only) with client side validation and observance of limits and
rules of course which were defined during online mode. ( Store This Queue
Somewhere)
I'm not reallyh sure that I want to go through with this however, this is
just a prototype idea.
On Sun, May 3, 2009 at 4:55 PM, Johan Compagner <jc...@gmail.com>wrote:
> I cannot believe that a typical wicket application (and a banking app
> fall under that category) does well in offline mode, to me offline
> mode works if the app is just about personal data (like gmail for your
> email) because if that is not the case and loads of none peronal ==
> shared data is used, how are you pushing that to the client? Maybe if
> the data is not thah much (not very likely in a banking app if you
> ask me) then you can push it to the client. But then when he gets
> online again you have to merge everything and resolve conflicts in the
> data...
>
> But wicket doesnt really play well for this at all. GWT or just
> another fat client like air or just java webstart would be better
>
> On 03/05/2009, Carlo Camerino <cm...@gmail.com> wrote:
> > hmm, you have a point here.however, every requirement is different.
> >
> > I know that it may sound weird, but still I believe that it depends on
> the
> > nature of the application.
> > There are lots of types of applications that banks use.
> > Some I know would have to always have a central server managing it.
> >
> > There are different types of Technical Architectures that we cater for in
> > our applications.
> > There are some applicationms that always require online mode regardless
> adn
> > there are applications that the user just
> > needs to be able to view customer information ,etc....
> >
> >
> > actually it's hard to decide here.
> > on the downside, I heard that GWT consumes a lot of resources on the
> client
> > side, it's also a consideration.
> >
> > Failsafe servers are of course an option but again, the network is still
> a
> > factor here.
> > For example a very slow connection to the central server makes my
> > productivity a lot less.
> > Some places suffer from low bandwidth, unreliable networks, etc...
> >
> > I saw the value of distributed or offline applications that uses
> > synchronization.
> > It will be harder for the developers of course sicne they have to cater
> to
> > two modes.
> > On Sun, May 3, 2009 at 1:55 PM, Vladimir K <ko...@gmail.com> wrote:
> >
> >>
> >> I would install failsafe cluster rather satisfying every client request
> >> about
> >> offline workability. You may end up implementing all the front-end and
> >> middle-end features in offline mode :)
> >>
> >> I believe offline mode should be used with care. The email applications
> >> are
> >> by nature offline. If you are certain that what the user does is offline
> >> by
> >> nature - implement it. If you have concerns that it should be involved
> >> into
> >> transaction (I mean a bit wider meaning than DB transaction) - implement
> >> it
> >> online and think about fail-safe servers.
> >>
> >> Concerning front-end and middle-end, AFAIK, every unit of work is a
> >> transaction which is done with multi-level authorization, including
> >> business
> >> authorization. You either implement all the authorization offline
> >> (insecure
> >> at all, and impossible in some cases) or defer authorization untill
> online
> >> mode (non-transactional). If a request of some client was satisfied (in
> >> offline mode) and then hasn't passed online authorization (for instance
> it
> >> violates some limits which can be thruly calculated on the server side
> >> only), you will have to call the client and tell him your appologises
> (or
> >> not directly you, then the bank. but the bank will then call you and
> tell
> >> you something awesome).
> >>
> >> Or just tell me the name of the bank. I will never become its client :)
> >>
> >>
> >> Carlo Camerino wrote:
> >> >
> >> > it's not for the public to use. but rather for people within the
> banks.
> >> > internal applications. sometimes central connection is not available.
> >> >
> >> > On Fri, May 1, 2009 at 9:37 PM, James Carman
> >> > <jc...@carmanconsulting.com>wrote:
> >> >
> >> >> Are you sure a banking application would be the right place for a
> >> >> gears-based implementation? Wouldn't it be kinda important to make
> >> >> sure the main server knows where everything is, when money is
> >> >> concerned?
> >> >>
> >> >> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino <cmcamerino@gmail.com
> >
> >> >> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > Is there any project which has Wicket And Google Gears Integration?
> >> >> > Wicket has really done a lot of us in speeding up development time.
> >> >> Coming
> >> >> > from a struts we saw the power of Wicket in terms its reusability
> and
> >> >> i've
> >> >> > noticed that
> >> >> > wicket already did most of the tasks that we would have to manually
> >> >> > do
> >> >> using
> >> >> > struts application, like session timeouts, redirects, etc....
> >> >> >
> >> >> > One of our main concerns however are that clients
> >> >> > are asking for our applications to be available even if the network
> >> >> > is
> >> >> down
> >> >> > or if the central server is down..
> >> >> > Currently we implemented our applications in a distributed fashion
> >> >> wherein
> >> >> > every branch ( Remote Location) has its own server.
> >> >> > However, this has implications of cost and administration issues.
> >> >> > However, if offline mode is enabled we can just begin syncing
> right.
> >> >> >
> >> >> > I think that Wicket WIth Google Gears Application will make it even
> >> >> better .
> >> >> >
> >> >> >
> >> >> > I think this is really a plus when it comes to marketing it to
> >> >> customers.
> >> >> > Most of the applications that we create our banking applications
> and
> >> >> any
> >> >> > downtime is costing our clients.
> >> >> >
> >> >> > Hopefully we can also do this to offload the central servers and to
> >> put
> >> >> > processing into client machines.
> >> >> >
> >> >> > One large problem I see though is that most code wil have to be
> moved
> >> >> to
> >> >> the
> >> >> > Browser Layer.
> >> >> > I'm thinking of how to create a wicket application which is mostly
> >> >> > run
> >> >> by
> >> >> > java classes work on the client side.
> >> >> > Looks as if there will be a lot of code changes...
> >> >> > I'm not really sure if it would be a totally different programming
> >> >> model.
> >> >> >
> >> >> > Anyone out there tried to integrate Gears And Wicket
> >> >> >
> >> >> > Carlo
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Wicket-Offline-Applications-tp23329675p23352910.html
> >> Sent from the Wicket - User 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 Offline Applications
Posted by Johan Compagner <jc...@gmail.com>.
I cannot believe that a typical wicket application (and a banking app
fall under that category) does well in offline mode, to me offline
mode works if the app is just about personal data (like gmail for your
email) because if that is not the case and loads of none peronal ==
shared data is used, how are you pushing that to the client? Maybe if
the data is not thah much (not very likely in a banking app if you
ask me) then you can push it to the client. But then when he gets
online again you have to merge everything and resolve conflicts in the
data...
But wicket doesnt really play well for this at all. GWT or just
another fat client like air or just java webstart would be better
On 03/05/2009, Carlo Camerino <cm...@gmail.com> wrote:
> hmm, you have a point here.however, every requirement is different.
>
> I know that it may sound weird, but still I believe that it depends on the
> nature of the application.
> There are lots of types of applications that banks use.
> Some I know would have to always have a central server managing it.
>
> There are different types of Technical Architectures that we cater for in
> our applications.
> There are some applicationms that always require online mode regardless adn
> there are applications that the user just
> needs to be able to view customer information ,etc....
>
>
> actually it's hard to decide here.
> on the downside, I heard that GWT consumes a lot of resources on the client
> side, it's also a consideration.
>
> Failsafe servers are of course an option but again, the network is still a
> factor here.
> For example a very slow connection to the central server makes my
> productivity a lot less.
> Some places suffer from low bandwidth, unreliable networks, etc...
>
> I saw the value of distributed or offline applications that uses
> synchronization.
> It will be harder for the developers of course sicne they have to cater to
> two modes.
> On Sun, May 3, 2009 at 1:55 PM, Vladimir K <ko...@gmail.com> wrote:
>
>>
>> I would install failsafe cluster rather satisfying every client request
>> about
>> offline workability. You may end up implementing all the front-end and
>> middle-end features in offline mode :)
>>
>> I believe offline mode should be used with care. The email applications
>> are
>> by nature offline. If you are certain that what the user does is offline
>> by
>> nature - implement it. If you have concerns that it should be involved
>> into
>> transaction (I mean a bit wider meaning than DB transaction) - implement
>> it
>> online and think about fail-safe servers.
>>
>> Concerning front-end and middle-end, AFAIK, every unit of work is a
>> transaction which is done with multi-level authorization, including
>> business
>> authorization. You either implement all the authorization offline
>> (insecure
>> at all, and impossible in some cases) or defer authorization untill online
>> mode (non-transactional). If a request of some client was satisfied (in
>> offline mode) and then hasn't passed online authorization (for instance it
>> violates some limits which can be thruly calculated on the server side
>> only), you will have to call the client and tell him your appologises (or
>> not directly you, then the bank. but the bank will then call you and tell
>> you something awesome).
>>
>> Or just tell me the name of the bank. I will never become its client :)
>>
>>
>> Carlo Camerino wrote:
>> >
>> > it's not for the public to use. but rather for people within the banks.
>> > internal applications. sometimes central connection is not available.
>> >
>> > On Fri, May 1, 2009 at 9:37 PM, James Carman
>> > <jc...@carmanconsulting.com>wrote:
>> >
>> >> Are you sure a banking application would be the right place for a
>> >> gears-based implementation? Wouldn't it be kinda important to make
>> >> sure the main server knows where everything is, when money is
>> >> concerned?
>> >>
>> >> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino <cm...@gmail.com>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > Is there any project which has Wicket And Google Gears Integration?
>> >> > Wicket has really done a lot of us in speeding up development time.
>> >> Coming
>> >> > from a struts we saw the power of Wicket in terms its reusability and
>> >> i've
>> >> > noticed that
>> >> > wicket already did most of the tasks that we would have to manually
>> >> > do
>> >> using
>> >> > struts application, like session timeouts, redirects, etc....
>> >> >
>> >> > One of our main concerns however are that clients
>> >> > are asking for our applications to be available even if the network
>> >> > is
>> >> down
>> >> > or if the central server is down..
>> >> > Currently we implemented our applications in a distributed fashion
>> >> wherein
>> >> > every branch ( Remote Location) has its own server.
>> >> > However, this has implications of cost and administration issues.
>> >> > However, if offline mode is enabled we can just begin syncing right.
>> >> >
>> >> > I think that Wicket WIth Google Gears Application will make it even
>> >> better .
>> >> >
>> >> >
>> >> > I think this is really a plus when it comes to marketing it to
>> >> customers.
>> >> > Most of the applications that we create our banking applications and
>> >> any
>> >> > downtime is costing our clients.
>> >> >
>> >> > Hopefully we can also do this to offload the central servers and to
>> put
>> >> > processing into client machines.
>> >> >
>> >> > One large problem I see though is that most code wil have to be moved
>> >> to
>> >> the
>> >> > Browser Layer.
>> >> > I'm thinking of how to create a wicket application which is mostly
>> >> > run
>> >> by
>> >> > java classes work on the client side.
>> >> > Looks as if there will be a lot of code changes...
>> >> > I'm not really sure if it would be a totally different programming
>> >> model.
>> >> >
>> >> > Anyone out there tried to integrate Gears And Wicket
>> >> >
>> >> > Carlo
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Wicket-Offline-Applications-tp23329675p23352910.html
>> Sent from the Wicket - User 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: Putting HTML files in src/main/webapp
Posted by Alan Garfield <al...@fromorbit.com>.
On Tue, 2009-05-05 at 08:26 -0400, Richard Allen wrote:
> To make Luther's point more explicit:
>
> Wicket allows you to bundle everything a Wicket component needs (Java code,
> HTML, CSS, images, etc.) into a single JAR and drop that JAR into the
> WEB-INF/lib directory of any WAR, thereby making the JAR essentially
> self-contained and reusable. The benefit this provides is the ability to
> truly componentize (or modularize) your web application. You can break a
> large project up into modules that become separate JAR Maven projects. Or
> you can break out reusable components into separate JAR Maven projects that
> get reused in different web applications.
>
> You can't take advantage of that if you put the resources in the root of
> WAR.
Thanks Richard, that really needs to be in the wiki somewhere. It's
clear and makes the advantages obvious. Previous to my question it all
appeared to be just for the sake of ease, but now it's rather apparent
why it is the way it is. I've read many sites/tutorials/mailing list
archives and the "Wicket in Action" book but it never was really
explained that well. Some even have their own differing confusing
opinions and variations. But then again maybe I just wasn't looking
right.
Regards,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Putting HTML files in src/main/webapp
Posted by Richard Allen <ri...@gmail.com>.
To make Luther's point more explicit:
Wicket allows you to bundle everything a Wicket component needs (Java code,
HTML, CSS, images, etc.) into a single JAR and drop that JAR into the
WEB-INF/lib directory of any WAR, thereby making the JAR essentially
self-contained and reusable. The benefit this provides is the ability to
truly componentize (or modularize) your web application. You can break a
large project up into modules that become separate JAR Maven projects. Or
you can break out reusable components into separate JAR Maven projects that
get reused in different web applications.
You can't take advantage of that if you put the resources in the root of
WAR.
-Richard
On Tue, May 5, 2009 at 4:03 AM, Luther Baker <lu...@gmail.com> wrote:
> > Separates the code from the templates so the designers don't have to
> > checkout the whole project, also keeps all the content in one directory.
> > Even though they are dynamic template files for wicket there is a
> > certain amount of static stuff that would be nice to be in one place.
> >
>
> If you simply want to separate the file types, you can separate the *.html
> files into the src/main/resources directory. That separates the Java code
> from the HTML templates, it gives you a completely separate directory tree
> for the *.html files and it keeps all the html content in one directory. In
> addition, it is standard Maven practice to separate non-Java files into the
> src/main/resources directory. All standard Maven builds should work just
> fine.
>
> Additionally, under Netbeans it seems to me to be rather daft that there
> > is a folder is called "Web Pages" in the project view but all it
> > contains is image/binary files and the WEB-INF directory.
>
>
> Just a little background, by definition, Wicket defines a non-traditional
> web application structure. It intentionally avoids the use of the web page
> directory structure you are likely used to. It turns out that to do what
> you
> are asking, you are actually fighting both Wicket and Maven. Traditional
> HTML and JSP pages can be visited directly - but not so with Wicket html
> files. They are read in from the classpath and much more tightly bound to
> an
> actual Java class.
>
> Trying to fit your Wicket app into a traditional structure can be done ...
> but it is not standard Wicket practice and you're going to end up with
> custom configuration that you'll have to manage.
>
>
> > But the actual
> > HTML files end up in the "Source Packages" or worse "Other Sources"
> > folder. I understand the reasons for putting them in the source packages
> > directories but it's not an ideal solution to my mind and my team.
>
>
> That is fair. If you're simply after your aforementioned points, try
> dropping the *.html files into src/main/resources.
>
> -Luther
>
Re: Putting HTML files in src/main/webapp
Posted by Alan Garfield <al...@fromorbit.com>.
On Tue, 2009-05-05 at 03:03 -0500, Luther Baker wrote:
> > Separates the code from the templates so the designers don't have to
> > checkout the whole project, also keeps all the content in one directory.
> > Even though they are dynamic template files for wicket there is a
> > certain amount of static stuff that would be nice to be in one place.
> >
>
> If you simply want to separate the file types, you can separate the *.html
> files into the src/main/resources directory. That separates the Java code
> from the HTML templates, it gives you a completely separate directory tree
> for the *.html files and it keeps all the html content in one directory. In
> addition, it is standard Maven practice to separate non-Java files into the
> src/main/resources directory. All standard Maven builds should work just
> fine.
Thanks that's pretty much where I've ended up.
> Additionally, under Netbeans it seems to me to be rather daft that there
> > is a folder is called "Web Pages" in the project view but all it
> > contains is image/binary files and the WEB-INF directory.
>
>
> Just a little background, by definition, Wicket defines a non-traditional
> web application structure. It intentionally avoids the use of the web page
> directory structure you are likely used to. It turns out that to do what you
> are asking, you are actually fighting both Wicket and Maven. Traditional
> HTML and JSP pages can be visited directly - but not so with Wicket html
> files. They are read in from the classpath and much more tightly bound to an
> actual Java class.
>
> Trying to fit your Wicket app into a traditional structure can be done ...
> but it is not standard Wicket practice and you're going to end up with
> custom configuration that you'll have to manage.
Thanks for the explanation, that makes sense to me now. You should
probably add something like this to the wiki as I couldn't find a really
good reason and the examples where a little light.
> > But the actual
> > HTML files end up in the "Source Packages" or worse "Other Sources"
> > folder. I understand the reasons for putting them in the source packages
> > directories but it's not an ideal solution to my mind and my team.
>
>
> That is fair. If you're simply after your aforementioned points, try
> dropping the *.html files into src/main/resources.
Thanks, it does seem a little silly to me as far as Netbeans is
concerned (also the million directories that might be needed to handle
com.foo.bar.web.pages.panels etc), but less than it did after your
explanation. It'll be fine with the files being in "Other
Sources/resources".
Many thanks Luther!
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Putting HTML files in src/main/webapp
Posted by Luther Baker <lu...@gmail.com>.
> Separates the code from the templates so the designers don't have to
> checkout the whole project, also keeps all the content in one directory.
> Even though they are dynamic template files for wicket there is a
> certain amount of static stuff that would be nice to be in one place.
>
If you simply want to separate the file types, you can separate the *.html
files into the src/main/resources directory. That separates the Java code
from the HTML templates, it gives you a completely separate directory tree
for the *.html files and it keeps all the html content in one directory. In
addition, it is standard Maven practice to separate non-Java files into the
src/main/resources directory. All standard Maven builds should work just
fine.
Additionally, under Netbeans it seems to me to be rather daft that there
> is a folder is called "Web Pages" in the project view but all it
> contains is image/binary files and the WEB-INF directory.
Just a little background, by definition, Wicket defines a non-traditional
web application structure. It intentionally avoids the use of the web page
directory structure you are likely used to. It turns out that to do what you
are asking, you are actually fighting both Wicket and Maven. Traditional
HTML and JSP pages can be visited directly - but not so with Wicket html
files. They are read in from the classpath and much more tightly bound to an
actual Java class.
Trying to fit your Wicket app into a traditional structure can be done ...
but it is not standard Wicket practice and you're going to end up with
custom configuration that you'll have to manage.
> But the actual
> HTML files end up in the "Source Packages" or worse "Other Sources"
> folder. I understand the reasons for putting them in the source packages
> directories but it's not an ideal solution to my mind and my team.
That is fair. If you're simply after your aforementioned points, try
dropping the *.html files into src/main/resources.
-Luther
Re: Putting HTML files in src/main/webapp
Posted by Alan Garfield <al...@fromorbit.com>.
On Tue, 2009-05-05 at 07:23 -0400, James Carman wrote:
> Ok, if you really want to do this and you don't want to use
> src/main/resources, have you checked out:
>
> http://wicketstuff.org/wicket13/customresourceloading/
>
> That has some code examples on how to load html templates from the
> document root. That might help you.
Thanks for that. I only just found that by chance in Google a few
minutes ago. Although upon my response from Luther I think I'll stick
with the files being in the resources directory. It's the least amount
of change (eg. none) and it suits my purposes fully.
Many thanks again,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Putting HTML files in src/main/webapp
Posted by James Carman <jc...@carmanconsulting.com>.
Ok, if you really want to do this and you don't want to use
src/main/resources, have you checked out:
http://wicketstuff.org/wicket13/customresourceloading/
That has some code examples on how to load html templates from the
document root. That might help you.
On Mon, May 4, 2009 at 9:31 PM, Alan Garfield <al...@fromorbit.com> wrote:
> On Mon, 2009-05-04 at 21:07 -0400, James Carman wrote:
>> What's the justification of having them in src/main/webapp again?
>
> Separates the code from the templates so the designers don't have to
> checkout the whole project, also keeps all the content in one directory.
> Even though they are dynamic template files for wicket there is a
> certain amount of static stuff that would be nice to be in one place.
>
> Additionally, under Netbeans it seems to me to be rather daft that there
> is a folder is called "Web Pages" in the project view but all it
> contains is image/binary files and the WEB-INF directory. But the actual
> HTML files end up in the "Source Packages" or worse "Other Sources"
> folder. I understand the reasons for putting them in the source packages
> directories but it's not an ideal solution to my mind and my team.
>
> Looking at the debug from org.apache.wicket.util.resource it looks like
> Wicket already looks for all and sundry anyway. How do I make it look in
> the webroot?
>
> Thanks,
> Alan.
>
>
>
> ---------------------------------------------------------------------
> 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: Putting HTML files in src/main/webapp
Posted by Alan Garfield <al...@fromorbit.com>.
On Mon, 2009-05-04 at 21:07 -0400, James Carman wrote:
> What's the justification of having them in src/main/webapp again?
Separates the code from the templates so the designers don't have to
checkout the whole project, also keeps all the content in one directory.
Even though they are dynamic template files for wicket there is a
certain amount of static stuff that would be nice to be in one place.
Additionally, under Netbeans it seems to me to be rather daft that there
is a folder is called "Web Pages" in the project view but all it
contains is image/binary files and the WEB-INF directory. But the actual
HTML files end up in the "Source Packages" or worse "Other Sources"
folder. I understand the reasons for putting them in the source packages
directories but it's not an ideal solution to my mind and my team.
Looking at the debug from org.apache.wicket.util.resource it looks like
Wicket already looks for all and sundry anyway. How do I make it look in
the webroot?
Thanks,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Putting HTML files in src/main/webapp
Posted by James Carman <jc...@carmanconsulting.com>.
What's the justification of having them in src/main/webapp again?
On Mon, May 4, 2009 at 8:28 PM, Alan Garfield <al...@fromorbit.com> wrote:
> On Mon, 2009-05-04 at 08:55 -0400, Richard Allen wrote:
>> If you are using <packaging>war</packaging>, then the maven-war-plugin will
>> automatically pick up the resources in src/main/webapp, which means you do
>> not have to configure that directory as a resource. Additionally, the
>> maven-resources-plugin automatically picks up resources in
>> src/main/resources, so you don't have to explicitly configure that either.
>> Try removing that configuration and see what happens.
>
>
> Thanks for that, but that's not really my issue. How do I make Wicket
> find the .html files in the root of the war? The hack I have with maven
> at the moment properly constructs the war by copying all the .html files
> into the classes folder for Wicket to find, but maven also helpfully
> copies them into the war's root as well creating duplicates in the war.
> This is what I'm trying to stop as it makes the war bigger than it needs
> to be, and is confusing to other developers if they look at the war.
>
> I've also tried to make Wicket load it's .html files from the root of
> the war, but I cannot seem to get the incantation right. I've tried to
> follow :-
>
> http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html#ControlwhereHTMLfilesareloadedfrom-InWicket1.3
>
> but I'm having little success.
>
> Thanks,
> Alan.
>
>
>
> ---------------------------------------------------------------------
> 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: Putting HTML files in src/main/webapp
Posted by Avraham Rosenzweig <av...@gmail.com>.
Try this:
http://www.mkyong.com/wicket/how-do-change-the-html-file-location-wicket/
On Tue, Sep 28, 2010 at 12:45 PM, elesi <js...@gmail.com> wrote:
>
> Could i change html resource folder, even if my project don't have a maven
> folder structure?
> I mean no resources folder, etc.?
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Wicket-Offline-Applications-tp1883788p2716953.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
>
>
--
[]'s
Avraham Rosenzweig
avrahamr@gmail.com
Re: Putting HTML files in src/main/webapp
Posted by elesi <js...@gmail.com>.
Could i change html resource folder, even if my project don't have a maven
folder structure?
I mean no resources folder, etc.?
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Offline-Applications-tp1883788p2716953.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: Putting HTML files in src/main/webapp
Posted by Steve Swinsburg <s....@lancaster.ac.uk>.
Ok glad you got it sorted.
For reference, you can adjust the excludes/includes in the build
section of the POM to exclude the HTML files from being added. Then
use the maven-war-plugin to take control of what goes where.
cheers,
Steve
On 5 May 2009, at 13:52, Alan Garfield wrote:
> On Tue, 2009-05-05 at 12:33 +0100, Steve Swinsburg wrote:
>> Alan,
>>
>> The fragment of XML from the pom that I posted IS in the Wicket
>> Quickstart generated via "mvn archetype:generate". It's also in the
>> pom when you use the helper code available here: http://wicket.apache.org/quickstart.html
>>
>> Hence why it's not a hack, it's standard Maven stuff. You don't need
>> the maven war plugin to generate the default war either.
>
> Indeed, but if you read my original post fully I wasn't asking about
> the
> resources folder or the standard way, I was wanting them in the webapp
> folder which with the default quickstart wicket pom doesn't work.
>
> And I quote myself "Thanks for that, but that's not really my issue.
> How
> do I make Wicket find the .html files in the __root of the war__? The
> hack I have with maven at the moment properly constructs the war by
> copying all the .html files into the classes folder for Wicket to
> find,
> but maven also helpfully copies them into __the war's root__ as well
> creating duplicates in the war."
>
> As you can see my "hack" comment wasn't talking about a standard
> structure hence my use of the word. My changed directory structure was
> the "hack". You read "hack" and completely missed my question for
> something else.
>
>
>> However, since you are doing it in a non standard way then you'll
>> need
>> the maven war plugin to assemble your war in the way you want.
>
> Indeed! Which was the reason for my original question. The war-plugin
> helpfully copies the contents of the webapp directory into the war,
> BUT
> if you also declare the resources as per the XML fragment to point at
> the webapp dir, then maven will copy the html files twice. Once into
> the
> classes directory structure as needed by Wicket and once into the
> webroot of the war as per the defaults of the war-plugin. That was my
> question, how do I stop maven (further the war-plugin) or how do you
> change the way Wicket loads the HTML so that I don't end up with two
> copies of the same files in the war.
>
> I may not have structure my question properly because I'm not fully
> versed with maven or wicket so you must excuse my inexperience.
>
>
>> You said this:
>>>> Thanks for that, but that's not really my issue. How do I make
>>>> Wicket
>>>> find the .html files in the root of the war?
>>
>>
>> So I gave you a link to do that. Since your HTML files will now be
>> in
>> a non standard location (ie not next to the classes) you will need to
>> configure your app to look in the location you desire, and that
>> information is available in the wiki link I posted:
>>>> http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html
>
> Again, I even posted that exact same link you quoted in the email you
> responded to!
>
>
>> All of this information is readily available; first search item for
>> the configuration, quickstart for pom.
>
> Well I must be not looking right, because it wasn't really apparent to
> me.
>
> I'm going to go with Luther's suggestion and use the default resources
> folder to make what I need to happen happen. That way there is no
> messing about with modifications to Wicket and no clumsy fiddling with
> maven to move files into and out of weird directory structures.
>
> Thanks anyway,
> Alan.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: Putting HTML files in src/main/webapp
Posted by Alan Garfield <al...@fromorbit.com>.
On Tue, 2009-05-05 at 12:33 +0100, Steve Swinsburg wrote:
> Alan,
>
> The fragment of XML from the pom that I posted IS in the Wicket
> Quickstart generated via "mvn archetype:generate". It's also in the
> pom when you use the helper code available here: http://wicket.apache.org/quickstart.html
>
> Hence why it's not a hack, it's standard Maven stuff. You don't need
> the maven war plugin to generate the default war either.
Indeed, but if you read my original post fully I wasn't asking about the
resources folder or the standard way, I was wanting them in the webapp
folder which with the default quickstart wicket pom doesn't work.
And I quote myself "Thanks for that, but that's not really my issue. How
do I make Wicket find the .html files in the __root of the war__? The
hack I have with maven at the moment properly constructs the war by
copying all the .html files into the classes folder for Wicket to find,
but maven also helpfully copies them into __the war's root__ as well
creating duplicates in the war."
As you can see my "hack" comment wasn't talking about a standard
structure hence my use of the word. My changed directory structure was
the "hack". You read "hack" and completely missed my question for
something else.
> However, since you are doing it in a non standard way then you'll need
> the maven war plugin to assemble your war in the way you want.
Indeed! Which was the reason for my original question. The war-plugin
helpfully copies the contents of the webapp directory into the war, BUT
if you also declare the resources as per the XML fragment to point at
the webapp dir, then maven will copy the html files twice. Once into the
classes directory structure as needed by Wicket and once into the
webroot of the war as per the defaults of the war-plugin. That was my
question, how do I stop maven (further the war-plugin) or how do you
change the way Wicket loads the HTML so that I don't end up with two
copies of the same files in the war.
I may not have structure my question properly because I'm not fully
versed with maven or wicket so you must excuse my inexperience.
> You said this:
> >> Thanks for that, but that's not really my issue. How do I make Wicket
> >> find the .html files in the root of the war?
>
>
> So I gave you a link to do that. Since your HTML files will now be in
> a non standard location (ie not next to the classes) you will need to
> configure your app to look in the location you desire, and that
> information is available in the wiki link I posted:
> >> http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html
Again, I even posted that exact same link you quoted in the email you
responded to!
> All of this information is readily available; first search item for
> the configuration, quickstart for pom.
Well I must be not looking right, because it wasn't really apparent to
me.
I'm going to go with Luther's suggestion and use the default resources
folder to make what I need to happen happen. That way there is no
messing about with modifications to Wicket and no clumsy fiddling with
maven to move files into and out of weird directory structures.
Thanks anyway,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Putting HTML files in src/main/webapp
Posted by Steve Swinsburg <s....@lancaster.ac.uk>.
Alan,
The fragment of XML from the pom that I posted IS in the Wicket
Quickstart generated via "mvn archetype:generate". It's also in the
pom when you use the helper code available here: http://wicket.apache.org/quickstart.html
Hence why it's not a hack, it's standard Maven stuff. You don't need
the maven war plugin to generate the default war either.
However, since you are doing it in a non standard way then you'll need
the maven war plugin to assemble your war in the way you want.
You said this:
>> Thanks for that, but that's not really my issue. How do I make Wicket
>> find the .html files in the root of the war?
So I gave you a link to do that. Since your HTML files will now be in
a non standard location (ie not next to the classes) you will need to
configure your app to look in the location you desire, and that
information is available in the wiki link I posted:
>> http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html
All of this information is readily available; first search item for
the configuration, quickstart for pom.
Steve
On 5 May 2009, at 10:11, Alan Garfield wrote:
> On Tue, 2009-05-05 at 08:32 +0100, Steve Swinsburg wrote:
>>
>> On 05/05/2009, at 1:28 AM, Alan Garfield wrote:
>>
>>>
>>> The hack I have with maven
>>> at the moment properly constructs the war by copying all the .html
>>> files
>>> into the classes folder for Wicket to find...
>>
>> What 'hack' do you need for Maven to include the HTML in the classes
>> directory? Presumably, since most other Wicket developers have their
>> HTML alongside their classes, they need this hack as well right? It's
>> just standard maven building:
>
> I didn't want to start a religious argument. I don't want to ruffle
> anyone's feathers. I didn't mean "hack" as a bad thing, I meant that I
> added a resource directive to Maven (ala below) to include the HTML
> from
> the webapp directory and it helpfully copied it twice as part of the
> war
> plugin. Without this "change" to the default wicket-quickstart POM
> Wicket still wouldn't find them. That was all I meant, hack was
> probably
> the wrong word and I apologies if I upset anyone. At the same time,
> why
> attack me when all I asked was a simple question I couldn't find the
> answer to elsewhere.
>
>
>> Add this to your POM to add everything except the Java source, as is.
>> It's even in the Maven quickstart:
>>
>> <build>
>> <resources>
>> <resource>
>> <filtering>false</filtering>
>> <directory>${basedir}/src/java</directory>
>> <includes>
>> <include>**</include>
>> </includes>
>> <excludes>
>> <exclude>**/*.java</exclude>
>> </excludes>
>> </resource>
>> </resources>
>> </build>
>>
>> Nonetheless, the first result from a search for wicket html location
>> (Safari even autofilled the last word for me) I found this:
>> http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html
>
> Thanks Steve for the added condescending tone there, but above isn't
> shown in the wiki you just posted (I also looked at that before
> posting,
> I even attempted to use the non-maven partitioning method but without
> much documentation on the PathStripperLocator and a working example I
> got lost).
>
> I posted here as a last resort to my question and wasn't looking to be
> verbally beaten up because I asked a question that might be outside
> the
> norm.
>
> Thanks anyway,
> Alan.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: Putting HTML files in src/main/webapp
Posted by Alan Garfield <al...@fromorbit.com>.
On Tue, 2009-05-05 at 08:32 +0100, Steve Swinsburg wrote:
>
> On 05/05/2009, at 1:28 AM, Alan Garfield wrote:
>
> >
> > The hack I have with maven
> > at the moment properly constructs the war by copying all the .html
> > files
> > into the classes folder for Wicket to find...
>
> What 'hack' do you need for Maven to include the HTML in the classes
> directory? Presumably, since most other Wicket developers have their
> HTML alongside their classes, they need this hack as well right? It's
> just standard maven building:
I didn't want to start a religious argument. I don't want to ruffle
anyone's feathers. I didn't mean "hack" as a bad thing, I meant that I
added a resource directive to Maven (ala below) to include the HTML from
the webapp directory and it helpfully copied it twice as part of the war
plugin. Without this "change" to the default wicket-quickstart POM
Wicket still wouldn't find them. That was all I meant, hack was probably
the wrong word and I apologies if I upset anyone. At the same time, why
attack me when all I asked was a simple question I couldn't find the
answer to elsewhere.
> Add this to your POM to add everything except the Java source, as is.
> It's even in the Maven quickstart:
>
> <build>
> <resources>
> <resource>
> <filtering>false</filtering>
> <directory>${basedir}/src/java</directory>
> <includes>
> <include>**</include>
> </includes>
> <excludes>
> <exclude>**/*.java</exclude>
> </excludes>
> </resource>
> </resources>
> </build>
>
> Nonetheless, the first result from a search for wicket html location
> (Safari even autofilled the last word for me) I found this:
> http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html
Thanks Steve for the added condescending tone there, but above isn't
shown in the wiki you just posted (I also looked at that before posting,
I even attempted to use the non-maven partitioning method but without
much documentation on the PathStripperLocator and a working example I
got lost).
I posted here as a last resort to my question and wasn't looking to be
verbally beaten up because I asked a question that might be outside the
norm.
Thanks anyway,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Putting HTML files in src/main/webapp
Posted by Steve Swinsburg <s....@lancaster.ac.uk>.
On 05/05/2009, at 1:28 AM, Alan Garfield wrote:
>
> The hack I have with maven
> at the moment properly constructs the war by copying all the .html
> files
> into the classes folder for Wicket to find...
What 'hack' do you need for Maven to include the HTML in the classes
directory? Presumably, since most other Wicket developers have their
HTML alongside their classes, they need this hack as well right? It's
just standard maven building:
Add this to your POM to add everything except the Java source, as is.
It's even in the Maven quickstart:
<build>
<resources>
<resource>
<filtering>false</filtering>
<directory>${basedir}/src/java</directory>
<includes>
<include>**</include>
</includes>
<excludes>
<exclude>**/*.java</exclude>
</excludes>
</resource>
</resources>
</build>
Nonetheless, the first result from a search for wicket html location
(Safari even autofilled the last word for me) I found this:
http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html
Steve
Re: Putting HTML files in src/main/webapp
Posted by Alan Garfield <al...@fromorbit.com>.
On Mon, 2009-05-04 at 08:55 -0400, Richard Allen wrote:
> If you are using <packaging>war</packaging>, then the maven-war-plugin will
> automatically pick up the resources in src/main/webapp, which means you do
> not have to configure that directory as a resource. Additionally, the
> maven-resources-plugin automatically picks up resources in
> src/main/resources, so you don't have to explicitly configure that either.
> Try removing that configuration and see what happens.
Thanks for that, but that's not really my issue. How do I make Wicket
find the .html files in the root of the war? The hack I have with maven
at the moment properly constructs the war by copying all the .html files
into the classes folder for Wicket to find, but maven also helpfully
copies them into the war's root as well creating duplicates in the war.
This is what I'm trying to stop as it makes the war bigger than it needs
to be, and is confusing to other developers if they look at the war.
I've also tried to make Wicket load it's .html files from the root of
the war, but I cannot seem to get the incantation right. I've tried to
follow :-
http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html#ControlwhereHTMLfilesareloadedfrom-InWicket1.3
but I'm having little success.
Thanks,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Putting HTML files in src/main/webapp
Posted by Richard Allen <ri...@gmail.com>.
If you are using <packaging>war</packaging>, then the maven-war-plugin will
automatically pick up the resources in src/main/webapp, which means you do
not have to configure that directory as a resource. Additionally, the
maven-resources-plugin automatically picks up resources in
src/main/resources, so you don't have to explicitly configure that either.
Try removing that configuration and see what happens.
-Richard
On Sun, May 3, 2009 at 7:19 AM, Alan Garfield <al...@fromorbit.com> wrote:
> Hi all,
>
> Just a quick question, I'd like to move all the .html files so my
> directory layout will be :-
>
> .
> |-- pom.xml
> \-- src
> |-- main
> | |-- java
> | | \-- com
> | | \-- foo
> | | |-- WicketApplication.java
> | | \-- bar.java
> | |-- resources
> | \-- webapp
> | |-- com
> | | \-- foo
> | | \-- bar.html
> | \-- WEB-INF
> \-- test
>
> I've setup my pom.xml like :-
>
> <build>
> <resources>
> <resource>
> <directory>src/main/resources</directory>
> </resource>
> <resource>
> <directory>src/main/webapp</directory>
> <includes>
> <include>**/*.html</include>
> </includes>
> </resource>
> [..]
> </resources>
> </build>
>
> Which works, but I end up with duplicate html files and directories in
> the root of the war. I've not found an easy way to change this default.
> Anyone else have an idea?
>
> Many thanks!
>
> Alan.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Putting HTML files in src/main/webapp
Posted by Alan Garfield <al...@fromorbit.com>.
Hi all,
Just a quick question, I'd like to move all the .html files so my
directory layout will be :-
.
|-- pom.xml
\-- src
|-- main
| |-- java
| | \-- com
| | \-- foo
| | |-- WicketApplication.java
| | \-- bar.java
| |-- resources
| \-- webapp
| |-- com
| | \-- foo
| | \-- bar.html
| \-- WEB-INF
\-- test
I've setup my pom.xml like :-
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
</resource>
<resource>
<directory>src/main/webapp</directory>
<includes>
<include>**/*.html</include>
</includes>
</resource>
[..]
</resources>
</build>
Which works, but I end up with duplicate html files and directories in
the root of the war. I've not found an easy way to change this default.
Anyone else have an idea?
Many thanks!
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Offline Applications
Posted by Vladimir K <ko...@gmail.com>.
Agree, I mentioned already it depends on the nature of the application.
Anyway unless the bank pays you on time-and-material basis it is risky to
implement two modes application (for bank and for dev team).
Consider Java Web Start vs Gears.
Carlo Camerino wrote:
>
> hmm, you have a point here.however, every requirement is different.
>
> I know that it may sound weird, but still I believe that it depends on the
> nature of the application.
> There are lots of types of applications that banks use.
> Some I know would have to always have a central server managing it.
>
> There are different types of Technical Architectures that we cater for in
> our applications.
> There are some applicationms that always require online mode regardless
> adn
> there are applications that the user just
> needs to be able to view customer information ,etc....
>
>
> actually it's hard to decide here.
> on the downside, I heard that GWT consumes a lot of resources on the
> client
> side, it's also a consideration.
>
> Failsafe servers are of course an option but again, the network is still a
> factor here.
> For example a very slow connection to the central server makes my
> productivity a lot less.
> Some places suffer from low bandwidth, unreliable networks, etc...
>
> I saw the value of distributed or offline applications that uses
> synchronization.
> It will be harder for the developers of course sicne they have to cater to
> two modes.
> On Sun, May 3, 2009 at 1:55 PM, Vladimir K <ko...@gmail.com> wrote:
>
>>
>> I would install failsafe cluster rather satisfying every client request
>> about
>> offline workability. You may end up implementing all the front-end and
>> middle-end features in offline mode :)
>>
>> I believe offline mode should be used with care. The email applications
>> are
>> by nature offline. If you are certain that what the user does is offline
>> by
>> nature - implement it. If you have concerns that it should be involved
>> into
>> transaction (I mean a bit wider meaning than DB transaction) - implement
>> it
>> online and think about fail-safe servers.
>>
>> Concerning front-end and middle-end, AFAIK, every unit of work is a
>> transaction which is done with multi-level authorization, including
>> business
>> authorization. You either implement all the authorization offline
>> (insecure
>> at all, and impossible in some cases) or defer authorization untill
>> online
>> mode (non-transactional). If a request of some client was satisfied (in
>> offline mode) and then hasn't passed online authorization (for instance
>> it
>> violates some limits which can be thruly calculated on the server side
>> only), you will have to call the client and tell him your appologises (or
>> not directly you, then the bank. but the bank will then call you and tell
>> you something awesome).
>>
>> Or just tell me the name of the bank. I will never become its client :)
>>
>>
>> Carlo Camerino wrote:
>> >
>> > it's not for the public to use. but rather for people within the banks.
>> > internal applications. sometimes central connection is not available.
>> >
>> > On Fri, May 1, 2009 at 9:37 PM, James Carman
>> > <jc...@carmanconsulting.com>wrote:
>> >
>> >> Are you sure a banking application would be the right place for a
>> >> gears-based implementation? Wouldn't it be kinda important to make
>> >> sure the main server knows where everything is, when money is
>> >> concerned?
>> >>
>> >> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino <cm...@gmail.com>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > Is there any project which has Wicket And Google Gears Integration?
>> >> > Wicket has really done a lot of us in speeding up development time.
>> >> Coming
>> >> > from a struts we saw the power of Wicket in terms its reusability
>> and
>> >> i've
>> >> > noticed that
>> >> > wicket already did most of the tasks that we would have to manually
>> do
>> >> using
>> >> > struts application, like session timeouts, redirects, etc....
>> >> >
>> >> > One of our main concerns however are that clients
>> >> > are asking for our applications to be available even if the network
>> is
>> >> down
>> >> > or if the central server is down..
>> >> > Currently we implemented our applications in a distributed fashion
>> >> wherein
>> >> > every branch ( Remote Location) has its own server.
>> >> > However, this has implications of cost and administration issues.
>> >> > However, if offline mode is enabled we can just begin syncing right.
>> >> >
>> >> > I think that Wicket WIth Google Gears Application will make it even
>> >> better .
>> >> >
>> >> >
>> >> > I think this is really a plus when it comes to marketing it to
>> >> customers.
>> >> > Most of the applications that we create our banking applications and
>> >> any
>> >> > downtime is costing our clients.
>> >> >
>> >> > Hopefully we can also do this to offload the central servers and to
>> put
>> >> > processing into client machines.
>> >> >
>> >> > One large problem I see though is that most code wil have to be
>> moved
>> >> to
>> >> the
>> >> > Browser Layer.
>> >> > I'm thinking of how to create a wicket application which is mostly
>> run
>> >> by
>> >> > java classes work on the client side.
>> >> > Looks as if there will be a lot of code changes...
>> >> > I'm not really sure if it would be a totally different programming
>> >> model.
>> >> >
>> >> > Anyone out there tried to integrate Gears And Wicket
>> >> >
>> >> > Carlo
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Wicket-Offline-Applications-tp23329675p23352910.html
>> Sent from the Wicket - User 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
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Wicket-Offline-Applications-tp23329675p23353287.html
Sent from the Wicket - User 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 Offline Applications
Posted by Carlo Camerino <cm...@gmail.com>.
hmm, you have a point here.however, every requirement is different.
I know that it may sound weird, but still I believe that it depends on the
nature of the application.
There are lots of types of applications that banks use.
Some I know would have to always have a central server managing it.
There are different types of Technical Architectures that we cater for in
our applications.
There are some applicationms that always require online mode regardless adn
there are applications that the user just
needs to be able to view customer information ,etc....
actually it's hard to decide here.
on the downside, I heard that GWT consumes a lot of resources on the client
side, it's also a consideration.
Failsafe servers are of course an option but again, the network is still a
factor here.
For example a very slow connection to the central server makes my
productivity a lot less.
Some places suffer from low bandwidth, unreliable networks, etc...
I saw the value of distributed or offline applications that uses
synchronization.
It will be harder for the developers of course sicne they have to cater to
two modes.
On Sun, May 3, 2009 at 1:55 PM, Vladimir K <ko...@gmail.com> wrote:
>
> I would install failsafe cluster rather satisfying every client request
> about
> offline workability. You may end up implementing all the front-end and
> middle-end features in offline mode :)
>
> I believe offline mode should be used with care. The email applications are
> by nature offline. If you are certain that what the user does is offline by
> nature - implement it. If you have concerns that it should be involved into
> transaction (I mean a bit wider meaning than DB transaction) - implement it
> online and think about fail-safe servers.
>
> Concerning front-end and middle-end, AFAIK, every unit of work is a
> transaction which is done with multi-level authorization, including
> business
> authorization. You either implement all the authorization offline (insecure
> at all, and impossible in some cases) or defer authorization untill online
> mode (non-transactional). If a request of some client was satisfied (in
> offline mode) and then hasn't passed online authorization (for instance it
> violates some limits which can be thruly calculated on the server side
> only), you will have to call the client and tell him your appologises (or
> not directly you, then the bank. but the bank will then call you and tell
> you something awesome).
>
> Or just tell me the name of the bank. I will never become its client :)
>
>
> Carlo Camerino wrote:
> >
> > it's not for the public to use. but rather for people within the banks.
> > internal applications. sometimes central connection is not available.
> >
> > On Fri, May 1, 2009 at 9:37 PM, James Carman
> > <jc...@carmanconsulting.com>wrote:
> >
> >> Are you sure a banking application would be the right place for a
> >> gears-based implementation? Wouldn't it be kinda important to make
> >> sure the main server knows where everything is, when money is
> >> concerned?
> >>
> >> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino <cm...@gmail.com>
> >> wrote:
> >> > Hi,
> >> >
> >> > Is there any project which has Wicket And Google Gears Integration?
> >> > Wicket has really done a lot of us in speeding up development time.
> >> Coming
> >> > from a struts we saw the power of Wicket in terms its reusability and
> >> i've
> >> > noticed that
> >> > wicket already did most of the tasks that we would have to manually do
> >> using
> >> > struts application, like session timeouts, redirects, etc....
> >> >
> >> > One of our main concerns however are that clients
> >> > are asking for our applications to be available even if the network is
> >> down
> >> > or if the central server is down..
> >> > Currently we implemented our applications in a distributed fashion
> >> wherein
> >> > every branch ( Remote Location) has its own server.
> >> > However, this has implications of cost and administration issues.
> >> > However, if offline mode is enabled we can just begin syncing right.
> >> >
> >> > I think that Wicket WIth Google Gears Application will make it even
> >> better .
> >> >
> >> >
> >> > I think this is really a plus when it comes to marketing it to
> >> customers.
> >> > Most of the applications that we create our banking applications and
> >> any
> >> > downtime is costing our clients.
> >> >
> >> > Hopefully we can also do this to offload the central servers and to
> put
> >> > processing into client machines.
> >> >
> >> > One large problem I see though is that most code wil have to be moved
> >> to
> >> the
> >> > Browser Layer.
> >> > I'm thinking of how to create a wicket application which is mostly run
> >> by
> >> > java classes work on the client side.
> >> > Looks as if there will be a lot of code changes...
> >> > I'm not really sure if it would be a totally different programming
> >> model.
> >> >
> >> > Anyone out there tried to integrate Gears And Wicket
> >> >
> >> > Carlo
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Wicket-Offline-Applications-tp23329675p23352910.html
> Sent from the Wicket - User 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 Offline Applications
Posted by Vladimir K <ko...@gmail.com>.
I would install failsafe cluster rather satisfying every client request about
offline workability. You may end up implementing all the front-end and
middle-end features in offline mode :)
I believe offline mode should be used with care. The email applications are
by nature offline. If you are certain that what the user does is offline by
nature - implement it. If you have concerns that it should be involved into
transaction (I mean a bit wider meaning than DB transaction) - implement it
online and think about fail-safe servers.
Concerning front-end and middle-end, AFAIK, every unit of work is a
transaction which is done with multi-level authorization, including business
authorization. You either implement all the authorization offline (insecure
at all, and impossible in some cases) or defer authorization untill online
mode (non-transactional). If a request of some client was satisfied (in
offline mode) and then hasn't passed online authorization (for instance it
violates some limits which can be thruly calculated on the server side
only), you will have to call the client and tell him your appologises (or
not directly you, then the bank. but the bank will then call you and tell
you something awesome).
Or just tell me the name of the bank. I will never become its client :)
Carlo Camerino wrote:
>
> it's not for the public to use. but rather for people within the banks.
> internal applications. sometimes central connection is not available.
>
> On Fri, May 1, 2009 at 9:37 PM, James Carman
> <jc...@carmanconsulting.com>wrote:
>
>> Are you sure a banking application would be the right place for a
>> gears-based implementation? Wouldn't it be kinda important to make
>> sure the main server knows where everything is, when money is
>> concerned?
>>
>> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino <cm...@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > Is there any project which has Wicket And Google Gears Integration?
>> > Wicket has really done a lot of us in speeding up development time.
>> Coming
>> > from a struts we saw the power of Wicket in terms its reusability and
>> i've
>> > noticed that
>> > wicket already did most of the tasks that we would have to manually do
>> using
>> > struts application, like session timeouts, redirects, etc....
>> >
>> > One of our main concerns however are that clients
>> > are asking for our applications to be available even if the network is
>> down
>> > or if the central server is down..
>> > Currently we implemented our applications in a distributed fashion
>> wherein
>> > every branch ( Remote Location) has its own server.
>> > However, this has implications of cost and administration issues.
>> > However, if offline mode is enabled we can just begin syncing right.
>> >
>> > I think that Wicket WIth Google Gears Application will make it even
>> better .
>> >
>> >
>> > I think this is really a plus when it comes to marketing it to
>> customers.
>> > Most of the applications that we create our banking applications and
>> any
>> > downtime is costing our clients.
>> >
>> > Hopefully we can also do this to offload the central servers and to put
>> > processing into client machines.
>> >
>> > One large problem I see though is that most code wil have to be moved
>> to
>> the
>> > Browser Layer.
>> > I'm thinking of how to create a wicket application which is mostly run
>> by
>> > java classes work on the client side.
>> > Looks as if there will be a lot of code changes...
>> > I'm not really sure if it would be a totally different programming
>> model.
>> >
>> > Anyone out there tried to integrate Gears And Wicket
>> >
>> > Carlo
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Wicket-Offline-Applications-tp23329675p23352910.html
Sent from the Wicket - User 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 Offline Applications
Posted by Carlo Camerino <cm...@gmail.com>.
ya, most bank applications are front end applications that simply require
that input be captured. and some minor validations.
Of course, there would be two modes, offline and online mode.
Would really be nice to implement this one.
On Fri, May 1, 2009 at 10:34 PM, James Carman
<jc...@carmanconsulting.com>wrote:
> ahhhhh, then proceed! :)
>
> It's an interesting idea. Don't know how it would work, though.
>
> On Fri, May 1, 2009 at 10:31 AM, Carlo Camerino <cm...@gmail.com>
> wrote:
> > it's not for the public to use. but rather for people within the banks.
> > internal applications. sometimes central connection is not available.
> >
> > On Fri, May 1, 2009 at 9:37 PM, James Carman
> > <jc...@carmanconsulting.com>wrote:
> >
> >> Are you sure a banking application would be the right place for a
> >> gears-based implementation? Wouldn't it be kinda important to make
> >> sure the main server knows where everything is, when money is
> >> concerned?
> >>
> >> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino <cm...@gmail.com>
> >> wrote:
> >> > Hi,
> >> >
> >> > Is there any project which has Wicket And Google Gears Integration?
> >> > Wicket has really done a lot of us in speeding up development time.
> >> Coming
> >> > from a struts we saw the power of Wicket in terms its reusability and
> >> i've
> >> > noticed that
> >> > wicket already did most of the tasks that we would have to manually do
> >> using
> >> > struts application, like session timeouts, redirects, etc....
> >> >
> >> > One of our main concerns however are that clients
> >> > are asking for our applications to be available even if the network is
> >> down
> >> > or if the central server is down..
> >> > Currently we implemented our applications in a distributed fashion
> >> wherein
> >> > every branch ( Remote Location) has its own server.
> >> > However, this has implications of cost and administration issues.
> >> > However, if offline mode is enabled we can just begin syncing right.
> >> >
> >> > I think that Wicket WIth Google Gears Application will make it even
> >> better .
> >> >
> >> >
> >> > I think this is really a plus when it comes to marketing it to
> customers.
> >> > Most of the applications that we create our banking applications and
> any
> >> > downtime is costing our clients.
> >> >
> >> > Hopefully we can also do this to offload the central servers and to
> put
> >> > processing into client machines.
> >> >
> >> > One large problem I see though is that most code wil have to be moved
> to
> >> the
> >> > Browser Layer.
> >> > I'm thinking of how to create a wicket application which is mostly run
> by
> >> > java classes work on the client side.
> >> > Looks as if there will be a lot of code changes...
> >> > I'm not really sure if it would be a totally different programming
> model.
> >> >
> >> > Anyone out there tried to integrate Gears And Wicket
> >> >
> >> > Carlo
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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 Offline Applications
Posted by James Carman <jc...@carmanconsulting.com>.
ahhhhh, then proceed! :)
It's an interesting idea. Don't know how it would work, though.
On Fri, May 1, 2009 at 10:31 AM, Carlo Camerino <cm...@gmail.com> wrote:
> it's not for the public to use. but rather for people within the banks.
> internal applications. sometimes central connection is not available.
>
> On Fri, May 1, 2009 at 9:37 PM, James Carman
> <jc...@carmanconsulting.com>wrote:
>
>> Are you sure a banking application would be the right place for a
>> gears-based implementation? Wouldn't it be kinda important to make
>> sure the main server knows where everything is, when money is
>> concerned?
>>
>> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino <cm...@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > Is there any project which has Wicket And Google Gears Integration?
>> > Wicket has really done a lot of us in speeding up development time.
>> Coming
>> > from a struts we saw the power of Wicket in terms its reusability and
>> i've
>> > noticed that
>> > wicket already did most of the tasks that we would have to manually do
>> using
>> > struts application, like session timeouts, redirects, etc....
>> >
>> > One of our main concerns however are that clients
>> > are asking for our applications to be available even if the network is
>> down
>> > or if the central server is down..
>> > Currently we implemented our applications in a distributed fashion
>> wherein
>> > every branch ( Remote Location) has its own server.
>> > However, this has implications of cost and administration issues.
>> > However, if offline mode is enabled we can just begin syncing right.
>> >
>> > I think that Wicket WIth Google Gears Application will make it even
>> better .
>> >
>> >
>> > I think this is really a plus when it comes to marketing it to customers.
>> > Most of the applications that we create our banking applications and any
>> > downtime is costing our clients.
>> >
>> > Hopefully we can also do this to offload the central servers and to put
>> > processing into client machines.
>> >
>> > One large problem I see though is that most code wil have to be moved to
>> the
>> > Browser Layer.
>> > I'm thinking of how to create a wicket application which is mostly run by
>> > java classes work on the client side.
>> > Looks as if there will be a lot of code changes...
>> > I'm not really sure if it would be a totally different programming model.
>> >
>> > Anyone out there tried to integrate Gears And Wicket
>> >
>> > Carlo
>> >
>>
>> ---------------------------------------------------------------------
>> 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 Offline Applications
Posted by Carlo Camerino <cm...@gmail.com>.
it's not for the public to use. but rather for people within the banks.
internal applications. sometimes central connection is not available.
On Fri, May 1, 2009 at 9:37 PM, James Carman
<jc...@carmanconsulting.com>wrote:
> Are you sure a banking application would be the right place for a
> gears-based implementation? Wouldn't it be kinda important to make
> sure the main server knows where everything is, when money is
> concerned?
>
> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino <cm...@gmail.com>
> wrote:
> > Hi,
> >
> > Is there any project which has Wicket And Google Gears Integration?
> > Wicket has really done a lot of us in speeding up development time.
> Coming
> > from a struts we saw the power of Wicket in terms its reusability and
> i've
> > noticed that
> > wicket already did most of the tasks that we would have to manually do
> using
> > struts application, like session timeouts, redirects, etc....
> >
> > One of our main concerns however are that clients
> > are asking for our applications to be available even if the network is
> down
> > or if the central server is down..
> > Currently we implemented our applications in a distributed fashion
> wherein
> > every branch ( Remote Location) has its own server.
> > However, this has implications of cost and administration issues.
> > However, if offline mode is enabled we can just begin syncing right.
> >
> > I think that Wicket WIth Google Gears Application will make it even
> better .
> >
> >
> > I think this is really a plus when it comes to marketing it to customers.
> > Most of the applications that we create our banking applications and any
> > downtime is costing our clients.
> >
> > Hopefully we can also do this to offload the central servers and to put
> > processing into client machines.
> >
> > One large problem I see though is that most code wil have to be moved to
> the
> > Browser Layer.
> > I'm thinking of how to create a wicket application which is mostly run by
> > java classes work on the client side.
> > Looks as if there will be a lot of code changes...
> > I'm not really sure if it would be a totally different programming model.
> >
> > Anyone out there tried to integrate Gears And Wicket
> >
> > Carlo
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket Offline Applications
Posted by James Carman <jc...@carmanconsulting.com>.
Are you sure a banking application would be the right place for a
gears-based implementation? Wouldn't it be kinda important to make
sure the main server knows where everything is, when money is
concerned?
On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino <cm...@gmail.com> wrote:
> Hi,
>
> Is there any project which has Wicket And Google Gears Integration?
> Wicket has really done a lot of us in speeding up development time. Coming
> from a struts we saw the power of Wicket in terms its reusability and i've
> noticed that
> wicket already did most of the tasks that we would have to manually do using
> struts application, like session timeouts, redirects, etc....
>
> One of our main concerns however are that clients
> are asking for our applications to be available even if the network is down
> or if the central server is down..
> Currently we implemented our applications in a distributed fashion wherein
> every branch ( Remote Location) has its own server.
> However, this has implications of cost and administration issues.
> However, if offline mode is enabled we can just begin syncing right.
>
> I think that Wicket WIth Google Gears Application will make it even better .
>
>
> I think this is really a plus when it comes to marketing it to customers.
> Most of the applications that we create our banking applications and any
> downtime is costing our clients.
>
> Hopefully we can also do this to offload the central servers and to put
> processing into client machines.
>
> One large problem I see though is that most code wil have to be moved to the
> Browser Layer.
> I'm thinking of how to create a wicket application which is mostly run by
> java classes work on the client side.
> Looks as if there will be a lot of code changes...
> I'm not really sure if it would be a totally different programming model.
>
> Anyone out there tried to integrate Gears And Wicket
>
> Carlo
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org