Vincent Massol wrote:
> 
> ----- Original Message -----
> From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, June 19, 2001 2:13 PM
> Subject: Re: [Rupert]: introduction : webapp development tools
> 
> > Vincent Massol wrote:
> > >
> > > hum ... I see ... But isn't this the goal for the Commons project as a
> whole
> > > ? I mean why is there a necessity to create an umbrella project like
> Rupert.
> >
> > Why do you say 'an umbrella'?  Where should we put it?  Cactus?  DBCP?
> > Digester?  Suggestions welcome.
> >
> > These are separate little miscellaneous tools that everyone seems to
> > reinvent.  And I would guess all of these are too small to stand on
> > their own.  So we need some kind of bucket to keep them in.
> >
> > If there is functionality from an existing commons component that can be
> > leveraged, it will be done.  Right now there are no tools that will add
> > two floating point numbers, for example, but it is something that people
> > want to do when using Velocity and WebMacro.  We believe that it's not
> > appropriate to be in the template language proper (just as it isn't in
> > JSP proper...), so custom tools are the solution.
> >
> 
> It's simply  a question of graininess I guess ... What I was saying is that
> I would not feel very comfortable to see some floating point math tools put
> into a web templating component project because the link between both is
> weak ...

Why do you say that? These are tools made by people *actually doing web
development*, and create these tools because they think they need them. 
We aren't inventing stuff hoping people will want them. These are things
that people need and use.  Why not collect them together and let people
reuse them?

> *However*, if there is not enough matter to start a full floating
> point library yes, I agree, why not put it in Rupert (or maybe better we can
> have a special generic component that act as a holder for anything too small
> to stand on it's own - Rupert is not generic as it's goal is to provide
> tools to help write webapps) ... and then if it groes move it to it's own
> project under jakarta-commons

What?  The idea here is not to make a 'junk drawer', but rather collect
stuff that people ask for over and over again.

> >
> > > We could say that all the components already under commons are for
> building
> > > web applications ... Why not continue by bringing small pieces of
> > > functionality, the goal being that each piece is independent from one
> > > another so that it can be used without using the whole ... ?
> >
> >
> > That's what we're doing.
> >
> > My original post was
> >
> > "Our intent is to start a webapp tool component - tools and utilities
> > that are useful in templates (and
> > JSPs)."
> >
> > So maybe that wasn't a good way to define it - the idea here is to have
> > a place for the zillions of little gadgets that people write when using
> > a templating language.  They are no different than the little zillions
> > of helper classes I assume people make for JSPs.  Sometimes, they wrap
> > them in a taglib, but I suspect that many times they don't.  In struts,
> > there is a bean access wrapper tag to make it easier.  What I would like
> > to see is if we can bring out some of the tools that Struts has wrapped
> > behind the bean wrapper so others can use.
> >
> >
> > > Also, is this done in concert with Turbine as I heard that they tried to
> > > remove a maximum of dependencies in their latest version (2.2 is it) so
> that
> > > a user could use only some part of it ...
> >
> > This has nothing to do with Turbine, other than Turbine might be able to
> > donate some tools.  There is no intention to bring in the Turbine
> > framework, like services management, the object-relational mapping, or
> > anything like that.
> >
> 
> no, I meant the generic utility classes not the service framework ...
> 
> > But the tool that helps manipulate and parse parameters in a
> > ServletRequest?  Sure.  That's general, framework independent, and
> > usable by lots of people.
> >
> exactly ...

So you are agreeing?
 
> > >
> > > Note that I am not saying that Rupert is not a good project ! Far from
> me to
> > > have this kind of idea ! I'm just trying to understand the rationale.
> >
> > This is good - if you don't understand, then I wasn't clear in my
> > description, and this helps make it better.  Keep pushing back!
> >
> 
> I will ... :-)
> 

See if you can summarize your case, bucause I am not following you.  I
don't see why this collection of tools, which clearly are needed since
people are making them on their own, is inappropriate for commons.

geir

-- 
Geir Magnusson Jr.                           [EMAIL PROTECTED]
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!

Reply via email to