forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: Filesystem layout (Re: Skin rewrite: 0.2 release?)
Date Tue, 12 Nov 2002 10:27:44 GMT
On Tue, Nov 12, 2002 at 10:10:37AM +0100, Nicola Ken Barozzi wrote:
> >Implication: you
> >want a semantic filesystem layout, as well as a semantic URI space.
> >Files are arranged according to what the _mean_, not what the _are_.
> >
> >Example: if we wanted:
> >
> >http://mysite/license
> >
> >then it's contents should be obtained from content/license.*, where the
> >extension (if present) is purely a hint to the sitemap as to which
> >pipeline to use.
> >
> >Is that what you're getting at?
> +1

good good..

> >My take on this is that the filesystem should be organized FIRST on
> >content type, THEN on semantics.  A direct analogy:
> >
> >FIRST we order projects by file type:
> >
> >src/java
> >src/test
> >src/scripts
> >src/etc
> >...
> >
> >THEN, inside each directory, we order by meaning:
> >
> >src/java/..../myproject/parsing/*.java
> >src/java/..../myproject/servlet/*.java
> >src/java/..../myproject/util/*.java
> >
> >
> >Likewise, in Forrest we should order first by type:
> >
> >content/xdocs
> >content/images
> >content/html
> >
> >then by meaning:
> >
> >content/xdocs/*.xml
> >content/xdocs/drafts/*.xml
> >content/xdocs/manual/*.xml
> >content/images/*.png
> >content/images/drafts/*.png
> >content/images/manual/*.png
> >content/html/sitemockups/*.html
> >
> >
> >Why do the initial split by content type?  Two reasons:
> >
> > - Users prefer it.  It provides a way of ordering one's project.  Users
> >   don't _want_ images and xdocs all jumbled together.
> I disagree.

Then please describe why Centipede doesn't have one big src/, given that
it's technically possible.

> Users have explicitely asked me to be able to have images where the
> content is.

"images where content is".. if you mean, move resources/images to
content/images then I'm all for that.

> Some are @ Avalon, not newbies.

Please direct them to this list in future.  Evidently they didn't know
that this can be easily achieved with:


That's the point: the current system, while supporting a structured
approach, _allows_ the unstructured approach if desired.  The reverse is
not true: if we go down your route of a sitemap full of
general-as-possible rules, we can never go back.  Fine-grained can
emulate coarse-grained, coarse-grained cannot emulate fine-grained.

> > - Simple pragmatism.  In projects, Ant needs to apply operations to
> >   _types_ of files, regardless of meaning.  In Forrest, exactly the same
> >   thing: we need to apply transformations based on _types_ of files,
> >   regardless of semantics.
> DTD states the type. It's in the file.

Just like Centipede could identify JUnit test cases with:

<fileset dir="src/" includes="**/*.java">
  <contains text="extends TestCase"/>

So again, given the technical feasibility, why doesn't Centipede merge
src/testcases and src/java?  Perhaps because.. it's a really dumb idea
that users won't buy? :)  If users won't buy it in Centipede, why would
Forrest users buy it here?

> >As for the second reason: yes we could 'infer' the content type by
> >looking at the extension, just like we could compile *.java wherever it
> >occurs under src/.  I just think it's cleaner to match on directory
> >rather than extension.
> Why?

For the same reasons an Ant script is made simpler by partitioning src/.
Everything is made simpler.  To start with, validation, which is the tip
of the iceberg of things broken in if we keep your
patch.  We might as well throw away and start again,
because right at the core is the assumption that content is separated by
type, and named with ${project.*-dir} properties.

> A gif file is a gif file whether I put it in a certain dir.
> If I *have* to do it it's because something is not clever enough to 
> understand it for me.
> >Here's a question: why does Centipede separate src/java from
> >src/documentation, when technically Ant could easily deal with everything
> >in a single src/ directory?  Why not, as you suggest for Forrest, order
> >by semantics, not type:
> >
> >src/util/*.java 
> >src/util/*.xml      # xdocs for 'util' code
> >src/servlet/*.java  # servlet interface
> >src/servlet/*.xml      # xdocs for servlet interface
> >
> >In fact, why not throw src/testcases/ in there too; we could always use
> >Ant selectors to distinguish JUnit source from normal source, just like
> >CAPs distinguish types of XML.
> Why does Java ask us to put html descriptions of the packages *in* the 
> class dirs?

Because Javadoc cannot assume otherwise.  But note that javadoc also
suggests that large quantities of docs be stored in doc-file/ subdirs.

> Why do we put properties there?

Laziness.  Personally I store non-Java files (manifests, properties,
resourcebundles) in a src/res (resources) tree.  For large projects it
really is much better.

> Because they are strictly related.
> Now, I'm not saying that we stuff *all* in the content dir, just *content*.
> I think that gifs, html, xml, etc are all content, and all are the same.


> We still have a resources dir, and *there* I would like to see what you 
> propose.

Ahem.. I am defending the status quo here, which you just broke ;P

> So users can decide to put images in the content, or treat them as 
> global "resources".
> It has been asked many times,

never on list...

> I don't see technical difficulties,

perhaps you haven't examined recently?

> I like it myself.
> What do others think?
> What do *users* really think?
> >Conclusion: history and experience show that ordering by type, and then
> >by meaning, provides something that a) users like, b) is technically
> >simple and unambiguous to deal with.
> My experience is different, that it's not always the case.
> We must cater for both behaviours, and also mixed ones.

+1.  Mine does, yours doesn't :)  Here's how the current system can
emulate yours:


That _works_ right now.  Any users who prefer a single content dir can do
just that.  Sure, they'll get 3 copies of the content/ directory in
build/tmp/, but it will work, and as soon as we eliminate the copy step
(by parametrising the sitemap) that problem will go away.

> On a list it has been written that some would commit images in the 
> content and move them to resources if used by more pages, giving a 
> simple migration path.

Can do that too.

> I like it.

:)  I think we need a proper Forrest roadmap, with use-cases and a
concrete, technical step-by-step guide, in order to prevent
misunderstandings like this from happening again.


View raw message