commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject RE: [HiveMind] extend BuildFactory to use static fields/methods
Date Wed, 01 Oct 2003 12:17:34 GMT
That seems like a different kind of service factory than BuilderFactory.  There's no reason
why
BuilderFactory has to be the only game in town, or be the kitchen sink ... we can have multiple
factories, even special purpose or single purpose factories.

There's a tradeoff between trying to address every special case in advance and managing the
documentation (not to mention the end-user's understanding of the framework). The more we
put in,
the more the users have to figure out.

My experience with Tapestry is that if you provide a good, flexible platform the users will
tell you
what they need.  HiveMind already puts Tapestry to shame (which makes sense, from my larger
view of
what HiveMind is intended for ... I split it out of Tapestry 3.0 so that I could use it in
Tapestry
3.1).

What's the biggest problem with Tapestry today?  The documentation hasn't kept up with the
code and
people are *very* frustrated.

So, for each feature, I've been asking myself:
- Is this absolutely necessary?
- Does it have to be in the core framework?
- How will I document this feature?


Finally, I think the best solution for a more general purpose service implementation factory
is to
make use of OGNL and/or Jython. With those solutions, you can basically "code" inside
hivemodule.xml. 

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com

> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Knut Wannheden
> Sent: Wednesday, October 01, 2003 1:51 AM
> To: commons-dev@jakarta.apache.org
> Subject: [HiveMind] extend BuildFactory to use static fields/methods
> 
> 
> Hi,
> 
> I was wondering whether it would make sense to extend the 
> BuildFactory service (or maybe add a new wervice) to also be 
> able to construct objects by returning the value of a classes 
> static field or by calling a static method on a class. The 
> former would obviously be simpler. E.g. (as a new service):
> 
> <invoke-factory service-id="hivemind.StaticBuilderFactory">
>  <construct class="foo.Bar" static-field="BAZ">
>   <set.../>
>  </construct>
> </invoke-factory>
> 
> --knut
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message