Re: Advice on Project Approach - Single or Multiple Apps?
Re: Advice on Project Approach - Single or Multiple Apps?
- Subject: Re: Advice on Project Approach - Single or Multiple Apps?
- From: Jake MacMullin <email@hidden>
- Date: Wed, 4 Feb 2004 09:07:24 +1100
The only problem with option 1 would be data caching issues. If you are
interacting with the *same* data through 2 (or more) different WO apps,
you will experience the effects of each app having a (potentially
conflicting) snapshot of the data.
This is only a problem if you don't plan for it. e.g. suppose you have
an 'update prices' app that your sales staff use to set current product
prices, and a 'display products' app that the public use to browse a
catalogue of products. The first time someone comes to view your
products (via the 'display products' app) - WebObjects gets data
related to those products out of the DB - however, on subsequent
requests for the same info, WebObjects is 'smart enough' to know that
it doesn't need to look at the DB again (it figures - "I know what's
there - I just looked, and I haven't changed it since - so I'm guessing
it is still the same"). The problem arises if one of your sales staff
has used a different app to interact with the same data - and changed
the prices. There is no 'built-in' mechanism for one WebObjects app
(the 'update prices' app) to tell another (the 'display products' app)
to refresh its cache of the data.
As I said, this is not necessarily a problem - the apps will continue
to run fine - but the 'display products' app will have out-of-date
information. The situation is complicated further if you want both apps
to write to the same data. Again, it will work - but if one app tries
to overwrite something the other app wrote - you'll get (and need to
handle) an Optimistic Locking Exception. If you consider the effects of
multiple apps accessing the same data, there is no reason why it won't
work - but it is something to be aware of.
HTH,
Jake MacMullin
On 04/02/2004, at 2:09 AM, Arturo Pirez wrote:
> On Feb 2, 2004, at 12:11 PM, Kieran Kelleher wrote:
>
> > 1) Build the whole thing as one complete single WebObjects
> application
> > myself getting page elements and graphic bits and pieces from graphic
> > design as required when constructing my WO HTML components, OR
> >
> > 2) Have graphic design build basic static HTML site for the "public"
> > portion with sales blurb and provide a number of separate WO
> > applications (all using the same EOModel/EOClasses framework) that
> are
> > accessible via URLS from the main static site.
> >
> > Thinking out loud, option 1 will have advantage of one login, one
> > session as a user navigates the site, particularly the private
> > "customer-tailored" and customer accounts portion, so I don't have to
> > worry about re-authenticating as the user moves from app to app.
> >
>
> Having been there, done that :-)
>
> I would go with option 2. The re-authentication issue can be handled
> easily by placing a cookie within
> the domain. If you're not allowed to use cookies then I would do
> option 1.
>
> ----
> WO in philadelphia - wanna cheesesteak with that?
> Please visit webobjects.meetup.com.
> _______________________________________________
> webobjects-dev mailing list | email@hidden
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/webobjects-dev
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.