cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@digitalinsight.com>
Subject FW: Config File Proposal (was... sort of...: [ANN] Apache Cocoon 2.1 Released - binary??)
Date Sun, 17 Aug 2003 07:38:52 GMT
Jay,

I think your post is just as valuable in the users group as well as in dev.
Although what we are trying to do with Cocoon may be somewhat different, I
believe the approach you are suggesting comes pretty darn close to what I
need.  Although I don't need all the cocoon parts and am OK with the blocks
concept, your approach to dealing with the configuration files is just what
the Dr. ordered.

Ralph

-----Original Message-----
From: Jay Freeman (saurik) [mailto:saurik@saurik.com]
Sent: Saturday, August 16, 2003 5:41 PM
To: Ralph Goers
Subject: Fw: Config File Proposal (was... sort of...: [ANN] Apache
Cocoon 2.1 Released - binary??)


Ralph:

I don't know if you are on the cocoon dev list, I did a search through my
mail and I only saw you post on the cocoon users list, but I sent this to
the dev list a little earlier (I had figured I'd not do rampant
cross-posting) and, after hearing your comments about "JUST my stuff" I was
wondering what you thought about it. Feel free to send replies to this back
to either mailing list if you feel that appropriate; I sent this directly to
you as it's really just a forward from the other list that I wanted you to
see and I wasn't really adding any new information content to it :). I also
tacked a reply that I sent to this post at the end.

Sincerely,
Jay Freeman (saurik)
saurik@saurik.com

----- Original Message -----
From: "Jay Freeman (saurik)" <saurik@saurik.com>
To: <dev@cocoon.apache.org>
Sent: Saturday, August 16, 2003 5:58 PM
Subject: Config File Proposal (was... sort of...: [ANN] Apache Cocoon 2.1
Released - binary??)


> The #1 thing that would help me start using Cocoon is orthogonal to a
> binary/source distribution issue (and I'll note my preference is towards
> binary on this axis).
>
> I agree with you (and the previous arguments, I read through the entire
> thread that was linked to) that taking Cocoon and getting it into a state
> where I can start making changes to it is one of the most irritating steps
> to getting Cocoon working. However, 2.1 hasn't changed this all that
> terribly much. (If you look at this e-mail and go "oh, he doesn't know how
> to use the build environment", please skip to "[START HERE]" later in the
> post before making a snap judgement on my point. If you want to just see
> what I'm proposing, skip to [PROPOSAL], although that skips part of the
> explanation of "why?".)
>
> The biggest issue to me is that Cocoon draws the line between where it
ends
> and my application begins at a different place than I do. To me, my
> application is a few lines in the map:components section, almost all of
> map:pipelines, and one or two configuration blocks in cocoon.xconf
(usually
> one). Everything else is "Cocoon", the framework on which I'm developing
my
> application.
>
> When I've seem people in some of these threads talking about using the
> custom build environment to get only what they want, I get the impression
> that they are talking about things like "don't install SVG support". To
me,
> I want _all_ of that installed. It's like installing a Linux distribution,
> and knowing there's some command line program that would be really useful,
> having many, many gigabytes of space devoted to /usr/bin, and _still_
> deciding "no, I don't want that". I ask back: WHY?!? :) Or like having
Java,
> and deciding "no, I'm never going to use java.util... I'm going to uncheck
> the box and not intall it".
>
> So when Stefano made the following point:
>
> maybe not all of them are beareded unix gurus (BTW, all the unix gurus I
> know don't have a beard, sign of the generation changes?) but for sure
> all of them want to use Cocoon to build stuff and I think (but maybe I'm
> wrong) they'd rather start small and grow than start huge and dismantle.
> [
>
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=cocoon-dev@xml.apache.or
> g&msgNo=12663 ]
>
> I want to say I agree with him for the actual application. I'd rather
write
> that myself. But I don't want to have to go "wait, I need SVG support...
> well, let's map that into the sitemap and do this and do that...".
>
> Having a tiny webapp that only contains the framework features I need is
the
> least of my concerns when I'm trying to get Cocoon working. What I want is
> the _entire_ framework to get installed, and absolutely _no_ application.
> This means I want almost (this almost is because some are samples) every
jar
> file Cocoon has to offer me, almost every
> generator/transformer/serializer/reader, almost every taglib, a pipeline
> devoid of anything at all except an error handler, and a virtually empty
> webapp context directory (at most one directory other than WEB-INF for the
> files needed for the default error handler, assuming these can't go in
> WEB-INF/error... I never checked to see if the pipeline is allowed to read
> out of there...). If there was a really easy way to get to this point,
> binary _or_ source, _I'd_ be super super happy.
>
> Now, this doesn't apply to services. I look carefully at what
> web/mail/whatever servers are going to get installed. In the case of
Cocoon,
> this would be HSQL. I don't use it, I have my own SQL server, I would
prefer
> it be installed (no harm in having the jar there), but be configured off
so
> it doesn't keep starting, listening on some port, and consuming whatever
> resources it uses when it's actually _running_ (something unused
generators
> don't do).
>
> What ended up happening to me with Cocoon 2.1 is I downloaded the new
source
> distribution and then had to learn the new build environment to try to get
> it to do that for me. Note that the new build environment doesn't seem to
be
> terribly documented... I did some recursive greps on the distribution to
try
> to figure out what some of the exclude.* options did and was only greeted
to
> build.xml files (of which were heavily factored out to use different
> variables to store things and beyond my comprehension at the time).
>
> I turned off all the samples I could find, even added some exclude.*
options
> that I found during the course of my grep that weren't even in the
original
> build.properties file. What I ended up with still had HSQL, but that's
> apparently because I didn't notice the block that would turn that off.
> However, my goal isn't really to turn that _off_ as much as would be to
> supress the configuration for it. I'd still want the jar there.
>
> [START HERE]
>
> I guess a big issue is that I not only host Cocoon for me, I host Cocoon
for
> other people on my web server. I try to offer it to them at the level of
> "here, go ahead, build yourself a webapp". If I tell them to ignore the
> map:components section, and to never ever look at cocoon.xconf, this
> actually works quite well. I have people happilly writing Cocoon
> applications who wouldn't be able to set it up for themselves on their own
> computers.
>
> So to me, Cocoon is _extremely_ a framework. It's just like installing PHP
> on the computer and adding the little "yes, we support that feature" box
in
> the "what we offer as a hosting provider" section (now, these are just
> friends of mine, it's not like I'm selling a service or something). If my
> users want to use HSQL, I want the jars to be there and ready to go, they
> would just need to configure it by adding a few simple XML elements to
some
> configuration file and then restarting their webapp (functionality I give
> them through Jakarta so they can restart Cocoon if they want to upload new
> jars for some class library they need).
>
> Now, this puts me in the position of upgrading their copies of Cocoon. The
> process of upgrading both their websites and mine is grueling right now.
The
> pipelines themselves have pretty much stayed the same since the
introduction
> of Cocoon 2, but I still need to deal with everything else. First I go
> through cocoon.xconf to unconfigure HSQL and the default database source
> that always gets configured (I'm pretty sure it got configured in 2.1 even
> though I wanted no samples... I did want the authorization framework, just
> no samples).
>
> Then I do the same thing to the sitemap. This was a little easier than
> before as most of the pipeline was clear. However, I still had to do it.
> There were some default pipeline entries for things like "" that pointed
to
> a welcome screen that I didn't want. Also, the files required for the
error
> handler are strewn all about... some in stylesheets/system,
> resources/scripts, resources/style, and the root directory of the webapp.
I
> then move all of those into a single folder and redo the sitemap
> appropriately. No matter who I'm setting up Cocoon for, myself or my
users,
> the error handler is crucial to doing development. I obviously want it.
But
> having it's files strewn all over the place is really irritating.
>
> Now comes the great merging of the sitemaps. My users haven't started
> writing custom generators and transformers, but I have for some of my own
> websites (I'm working on an EXIF generator for grabbing digital camera
> information from JPEG files based on some classes from a guy named Drew
that
> I found on the web). What would be ideal is if I could just copy the new
> framework configuration over the old one (as I really don't touch any of
> that), and leave my application configuration alone.
>
> However, as mentioned before, Cocoon doesn't draw that line where I do. I
> draw that line halfway through the configuration files :). The #1 thing
that
> would help me (and I consider myself rather experienced with cocoon), and
> I'd imagine help a lot of beginners alike, is to have 4 main configuration
> files instead of 2. Yes, that's more, but it's going to add a lot of
> "seperation of concerns", and I know we love that, hehe.
>
> [PROPOSAL]
>
> What I would want is for each current configuration file to get split in
2,
> one for base configuration, one for local configuration. For the sitemap,
> the pipelines go in the latter (although error handlers can be defined in
> the prior one and overridden in the latter), and components can go in
either
> (the configurations here are merged, although names from the latter
override
> names from the former). Similar process for cocoon.xconf. All the
> configuration of how XSP works stays in the base configuration, buy my
> single jdbc datasource configuration entry goes in the local one.
>
> This way, I could download a new version of Cocoon (either binary or
source,
> whatever) and just copy over the old configuration on all of my websites,
> merge the jar files (this is irritating... it would be really nice if we
> could have a local-lib or something in WEB-INF that specified the jar
files
> that were particulr to the Cocoon application and didn't have to do with
> Cocoon itself, although I realize that may be really hard or even
impossible
> if it causes issues with the Servlet standard) and as long as my pipeline
> was still compatible it would work. I wouldn't need to do the three way
> merge operation between my version's pristine sitemap, my sitemap, and the
> new pristine sitemap.
>
> Also, this would mean that I'd have files that were just my app. I
wouldn't
> have to scroll down almost _300 lines_ (and that's using my formatting of
> the XML files, which is a hell of a lot more compressed than what it comes
> with) in the sitemap.xmap file to find something I consider mine (or find
> the _one configuration block_ in cocoon.xconf that I consider mine). One
of
> the big hurdles _I've_ had to go through when I try to teach new users how
> to work with Cocoon is to tell them: "The map:components section may seem
> really scary and has lots of configuration; but you really don't have to
> know how that works for you to use Cocoon. All you really need to know is
it
> sets up the default generators/transformers/serializers... don't break
it."
>
> Sincerely,
> Jay Freeman (saurik)
> saurik@saurik.com
>
> ----- Original Message -----
> From: "Geoff Howard" <cocoon@leverageweb.com>
> To: <users@cocoon.apache.org>
> Cc: <dev@cocoon.apache.org>
> Sent: Saturday, August 16, 2003 5:21 PM
> Subject: Re: [ANN] Apache Cocoon 2.1 Released - binary??
>
>
> > Sam Chance wrote:
> > > As a user...the binary is essential.  I understand it makes it easier
> for
> > > the developers, but I think the issue needs to be revisited with an
> intent
> > > to distribute a binary.
> >
> > Ok, first of all - I hear you and will raise this issue again on the dev
> > list. (cc'd).  Can I ask you to elaborate on why you think the one step
> > build is just out of the question for you?  Is it the ease of first use
> > when evaluating?  Is it the build time?  Is there something not provided
> > that is needed?  Honestly, everyone has been very open minded about this
> > but had a hard time coming up with a quantifiable reason.
> >
> > But also,
> > - just to reiterate.  This was not meant to make it easier on the
> > developers, but the users.  It was observed that Cocoon is not really a
> > thing that you just "use" -- it's a framework that lets you develop
> > something.  And starting that process was very painful with a binary
> > distribution and it is much better with the current one.  There is just
> > so much in the distribution that any one person doesn't need all of it.
> > - this was never intended as a permanent direction for Cocoon.  The
> > arrival of hot-pluggable "real" blocks in (probably) the next release
> > will give the best of both worlds.
> >
> > Geoff

----- Original Message -----
From: "Jay Freeman (saurik)" <saurik@saurik.com>
To: <dev@cocoon.apache.org>
Sent: Saturday, August 16, 2003 7:19 PM
Subject: Re: Config File Proposal (was... sort of...: [ANN] Apache Cocoon
2.1 Released - binary??)


> I forgot to mention this, but if people like this idea I'd be willing to
be
> the one to actually have to try to make it happen.
>
> Also, I'd like to point out the way I've envisioned/described it would be
> backwards compatible with the current setup and a blank base
configuration.
> The case of cocoon.xconf would be to just increase the search path for
> configuration to both files, so having all the configuration in the local
> file shouldn't be a problem, and having all the components configured in
the
> local file also wouldn't be a problem (the base cocoon.xconf could even
just
> be detected as "not there" and ignored, and the base sitemap could just
not
> be specified in cocoon.xconf and therefor not looked for).
>
> The last thing is maybe there's some obvious way to actually do this
> seperation of configuration now and I just never knew about it.... in
which
> case, anyone mind letting me in on the secret? :) Please? hehe
>
> Sincerely,
> Jay Freeman (saurik)
> saurik@saurik.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message