ounder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : Kyrre Kristiansen [mailto:kyrre_kristian...@yahoo.co.uk]
Envoyé : lundi 13 avril 2009 02:03
À : discuss@restlet.tigris.org
Objet : Re: Resource fac
--
Kyrre Kristiansen
--- On Wed, 8/4/09, Tim Peierls wrote:
> From: Tim Peierls
> Subject: Re: Resource factories
> To: discuss@restlet.tigris.org
> Date: Wednesday, 8 April, 2009, 3:26 PM
> On Tue, Apr 7,
> 2009 at 10:28 AM, Kyrre Kristiansen
> wrote:
>
> Th
On Tue, Apr 7, 2009 at 10:28 AM, Kyrre Kristiansen <
kyrre_kristian...@yahoo.co.uk> wrote:
> This resulted in using Generics on my resources, where I created a class,
> ListResource (where Referrable is an interface, with
> one method, getId() ). ... a concrete class that relies solely on one
> o
Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : Kyrre Kristiansen [mailto:kyrre_kristian...@yahoo.co.uk]
Envoyé : mardi 7 avril 2009 16:28
À : discuss@restlet.tigris.org
Objet : RE: Resource factories
Hello
e before you allow
creation and modification of a child resource. Twenty or so more
resource types under the belt, and I might get there ;-)
*end rant*
Kyrre Kristiansen
--- On Thu, 26/3/09, Jerome Louvel wrote:
he reasons stated in this thread already).
That, however is not a big deal.
Kyrre Kristiansen
--- On Tue, 7/4/09, Rhett Sutphin wrote:
> From: Rhett Sutphin
> Subject: Re: Resource factories
> To: discuss@restlet.tigris.org
hierarchies where you have to
> check for the existence of a parent resource before you allow
> creation and modification of a child resource. Twenty or so more
> resource types under the belt, and I might get there ;-)
>
> *end rant*
>
> -----
get
there ;-)
*end rant*
Kyrre Kristiansen
--- On Thu, 26/3/09, Jerome Louvel wrote:
> From: Jerome Louvel
> Subject: RE: Resource factories
> To: discuss@restlet.tigris.org
> Date: Thursday, 26 March, 2009, 1:20 PM
>
>
>
>
>
> Hi all,
>
&
~ <http://www.noelios.com/>
http://www.noelios.com
_
De : Tal Liron [mailto:tal.li...@threecrickets.com]
Envoyé : jeudi 26 mars 2009 08:49
À : discuss@restlet.tigris.org
Objet : Re: Resource factories
Thanks to all who replied on this. After a discussion on the code list, i
Thanks
to all who replied on this. After a discussion on the code list, it
became clear that the Restlety solution to configuring resources is to
use the Context. The Context has a ConcurrentMap of attributes,
described as so:
"This is a convenient mean[s] to provide common objects to all
the
cc
Subject
Please respond to Re: Resource factories
Thanks,
Tim. I intended these static non-final fields to be, by convention,
only modified during the configuration mode, but in any case didn't do
much because I'm still looking for a comprehension solution to the (can
we call it?) constructor injection problem.
Your
post did come through on
I had almost finished drafting a response, but as usual Rob said it all
better than I could.
Let me emphasize that construction of short-lived objects like Resources is
going to be much faster and less error-prone than managing state shared
across multiple requests. Doug Lea has said that if you ca
[Tried sending to code list, but I'm not sure it got through.]
Well, there are definitely some concurrency bugs here. Using public static
non-final fields is a big no-no.
Even if you made all this thread-safe, it's problematic: What if two
separate Applications (in the same class loader, but from
Small
addendum:
Instead
of checking out svn, I think the development documentation may be good
enough for reference:
http://www.restlet.org/documentation/snapshot/ext/index.html?org/restlet/ext/script/package-summary.html
-Tal
Thanks,
Rob! I value your gut instinct in this.
Perhaps,
then, we can indeed move this over the code review side. Specifically,
I would be very happy if you and others could take a look at the script
extension I am working on in Restlet svn. It has two Resource-based
classes that currently re
In addition to what Rhett said ... one massively huge benefit of
having Resources that are created per-request is that they need not be
thread safe. Very few developers (:: cough :: except Tim) can do
concurrency correctly every time.
But I've spent most of the afternoon noodling over this discus
Hi Dave,
On Mar 23, 2009, at 3:08 PM, David Bordoley wrote:
> Out of curiosity is there a reason why Resource isn't implemented as a
> subclass of Restlet? It seams like there is a lot of overhead in
> initializing a new Resource on every request especially when a lot of
> salient features such a
Out of curiosity is there a reason why Resource isn't implemented as a
subclass of Restlet? It seams like there is a lot of overhead in
initializing a new Resource on every request especially when a lot of
salient features such as what methods,variants, etc that are supported
tend to static for a g
Ah,
thanks, Rob. You've captured what I think is the main problem here: it
has
more to
do with the Resource class than the Finder class specifically. Restlet
expects extensions of class Resource to have a
specific constructor. Of course, you don't have to implement that
specific constructor --
I'd be careful of judgement-words like "bad practices" since this implies
some universal level of harm in all cases. I think the current Finder
design is simplistic, flexible, and easy to implement. I think there is
also room for a more structured base implementation that exposes some
advantages
Good
point, Rhett.
Well,
let me put it this way -- do you think the current Finder design
encourages bad practices for Restlet users?
-Tal
Rhett Sutphin wrote:
I don't think that subclassing Finder to be more factory-like goes
against Restlet's design. The default finder is a ver
Hi Tal,
On Mar 23, 2009, at 1:06 PM, Tal Liron wrote:
> Thanks, Tim. This is a reasonable workaround -- creating a factory
> where one isn't there. And Guice adds some elegance to your
> solution. Another solution is simply to rewrite Finder entirely to
> use factories. This isn't hard. But
Thanks, Tim. This is a reasonable workaround --
creating a factory where one isn't there. And Guice adds some elegance
to your solution. Another solution is simply to rewrite Finder entirely
to use factories. This isn't hard. But it also goes against Restlet's
current design.
One of the very n
I tried to solve this problem in a limited way, using Guice, and wrote about
it here:
http://tembrel.blogspot.com/2008/07/resource-dependency-injection-in.html
Maybe some of this could adapted for your purposes.
--tim
On Fri, Mar 20, 2009 at 10:03 PM, Tal Liron wrote:
> Hey Restleters,
>
>
>
Hey
Restleters,
Sorry
if this question has been answered before -- I'm rather new to the
community, even though I've been a heavy Restlet user for a while.
I
understand and agree with abstract class design used by Restlet, as is
detailed by the wiki:
http://wiki.restlet.org/developers/179
26 matches
Mail list logo
