• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Concurrent request handling
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concurrent request handling


  • Subject: Re: Concurrent request handling
  • From: Chuck Hill <email@hidden>
  • Date: Thu, 07 Apr 2011 09:00:10 -0700

On Apr 7, 2011, at 8:09 AM, Dev WO wrote:

> Hello Andrew,
>
>>
>> Hi Xavier;
>>
>> I would suggest not putting the formatter in the EO class because the EO is model layer and the formatter really belong as part of the display logic -- blurring the two eventually ends up causing design problems in the long-haul.
>
> I completely agree with this:)
>
>> I think in the past when faced with this situation, I added accessors to the components' controllers' super-class which then "gets or creates" a formatter for a particular purpose (data quantity format / timestamp / currency etc...) which is cached in the "user info" in the WOContext instance for the current request-response cycle.  This approach allows you to re-use the formatters for the request-response cycle and then just allows them to be garbage collected at the end of the cycle.
>
> That means I would have as much formatter instances as there's a request for a specific component/page. It's probably not a big deal, it just feels strange to me to have something that is application-wide used in a component part.

A compared to String or Integer or... :-)  Formatters should be lightweight objects that can be created, used, and discarded at will.  Caching and re-using them is just an easy and obvious optimization.  Also, some formatters ARE thread safe.  It is the date formatting ones that seem to be a problem.


> Would it be a better practice to implement those formatter in a component super-class or have them as an interface for the components that need them?

They would have to be static to be in an interface and that is not thread safe.  :-)  I'd do what Andrew suggests or just create what you need in your component constructor.  If it is a stateless app, just keep the page cache very small and you don't have to worry about memory.


Chuck


>> cheers.
>>
>>> Sorry to jump into this to add another question:)
>>> But I would have expected the formatter to not be an issue as it's not
>>> actually writing data.
>>> If you have a stateless app (like full of DA), how would you handle that
>>> as you can actually put the formatter in Session?
>>> Do you have to put the formatter inside the EO class?
>>
>> --
>> Andrew Lindesay
>> www.silvereye.co.nz
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list      (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list      (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden

--
Chuck Hill             Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects







Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Concurrent request handling (From: Mark Wardle <email@hidden>)
 >Re: Concurrent request handling (From: Chuck Hill <email@hidden>)
 >Re: Concurrent request handling (From: Matteo Centro <email@hidden>)
 >Re: Concurrent request handling (From: Chuck Hill <email@hidden>)
 >Re: Concurrent request handling (From: Dev WO <email@hidden>)
 >Re: Concurrent request handling (From: Andrew Lindesay <email@hidden>)
 >Re: Concurrent request handling (From: Dev WO <email@hidden>)

  • Prev by Date: Re: PHP Customer Request
  • Next by Date: Re: PHP Customer Request
  • Previous by thread: Re: Concurrent request handling
  • Next by thread: Re: Concurrent request handling
  • Index(es):
    • Date
    • Thread