forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: Link-Addressing, and breaking up the sitemap
Date Thu, 05 Sep 2002 07:51:55 GMT
Jeff Turner wrote:
> On Tue, Sep 03, 2002 at 01:50:57PM +0200, Marc Portier wrote:
> ...
> 
>>for this last part I still think a simple forrest-config file 
>>makes the most sense: (since I don't know how to have ant run 
>>through properties that you don't know about at design time)
>>
>><content>
>>  <part name="doc"
>>        location="./src/documentation/content/xdocs"/>
>>  <part name="mail"
>>        location="..." />
>>  <part name="jdoc"
>>        location="..." />
>></content>
>>
>>with the knowledge of the current bot we could easily build out 
>>of this a dynamic/embedded ant piece that gets to copy over this 
>>stuff to the cocoon context dir in separate dirs that == the 
>>part-name
> 
> 
> This sounds much like Marc's siteplan idea, where an XML file contains
> project-specific details that result in various sitemap modifications.
> 

it does, I have felt some resent to the idea of generating 
sitemap contents though, so I'm trying to find solutions that do 
not require that, yet still solve the issues we are facing...

Still: configuring the load of what forrest should know about 
your project all in *one* file seems logic to me.  (as long as it 
is all inside the one concern which I would largely define as 
"organize the project site" This would be involving: choosing 
some skin, and maybe setting some skin-specific customizations, 
decide on which parts get hooked up in which tabs, setup the 
libre auto-indexing rules, ...

Even if the concerns would grow out of one role (person) this 
could still be the entry config-file that maybe lists where other 
files are.

(ATM you just need to know, or take the hurdle of sitemap reading 
  to know what where enables which effect, and IMHO having better 
documentation is more a patch then an in depth solution: 
documenting one config file will also be easier and more clear 
then...)


> One issue..
> 
> I think it should always be possible to use Forrest sites offline or
> online. For this to work, links to external things like javadocs need to
> work 'statically' as well. It's no good having links starting with
> '/jdoc', because in a static site they'll be interpreted relative to the
> site root, not the forrest root.
> 

Well hidden in another side-track of this thread I launched 
another solution for this to Nicola (he has the cocoon CLI knowledge)

<snip 
from="http://marc.theaimsgroup.com/?l=forrest-dev&m=103097448015510&w=2">

 >> by the way Nicola: the CLI should also be the one that
 >> "relativizes" all the none http://-leading hrefs in our
 >> generated html as well :-D
 >> that is the correct way to produce a bunch of relative
 >> interconnected pages that can be placed where-ever (not just
 >> in the /forrest) on a webserver. (and detaches the solution
 >> from the webapp that doesn't have this concern)

</snip>

whadayathink?
using the CLI is about "staticalizing" your content.  The webapp 
does not have this concern, so only the CLI needs to be taking up 
this concern to 'relativise' all the /-leading references in the 
produced static content.
(At first I mentioned some transformer for this, but 'in office' 
Steven correctly pointed out that this has only got to do with 
the use of the crawler.)

> We could just have an Ant task that replaces '/jdoc' with the correct
> path, adding extra ..'s to compensate for subdirectories.
> 

yes, but writing that inside the CLI seems more logic, no?
maybe it could be a switch to enable/disable this behaviour
although IMHO people should not of have been exploiting this 
quirk in the current CLI as a feature (I know forrest did, though)

> 
>>what remains though is the knowledge of the "default-page" for 
>>each of the parts... what if we link to just /doc/ ? must there 
>>then be some /content/doc/index.* ?
>>if we make this flexible and possibly differrent for the various
> 
> 
> How about just adding a 'default' attribute to the above XML?
> 

That was my original plan, only this feature DOES push more into 
the direction of generation of the sitemap, which is a path I try 
to avoid ATM.

Only solution I see now, is just to make this kinda 'fix'
after all the real world web has this thing with index.html as 
well, right? (I expect you to have some emotions, Jeff, given 
your recent train of thought on the URI's :-))

> 
>>there is one other thing we could mingle in here, and that is the 
>>tab-definitions:
>><content>
>>  <tab label="must reads" default-part="doc">
>>    <part name="doc" location=".." />
>>    <part name="jdoc" location=".." />
>>  </tab>
>>  <tab label="community" defaut-part="mail">
>>    <part name="mail">
>>  </tab>
>>  <part name=".." location=".." />
>></content>
>>
>>so we could also generate a tabs.xml :-)

it would also more clearly define what tabs are (there is some 
history around that discussion)

in fact it would define them as the tabs you find in the (real 
paper!) books (cuts or colours on the edges of the sheets)
- they are somewhat partitioning the book: each page is in a 
section (part) of which some of them can be grouped in tabs
- each page (you reference by number) knows from itself in which 
section and tab it lives --> you know which one to highlight
- the 'tab' functions as a bookmark (the cut-out ones) in that if 
you open the book at the tab, then you're on the default (first) 
page of the default (first) section (part) of that book

> 
> 
>>>From what I gather of the siteplan proposal, the idea was to have one XML
> file that effectively configures the whole of Forrest for the user's

yes. that surely still holds (soc in my book also means grouping 
everything of one concern :-) there is already enough files to 
attend to, right?)

> project.  From that XML siteplan file, one would generate XML catalogs,
> tab files, book files (integrate libre.xml?), and do lots of tweaking of
> the sitemap, and generate parameters for the skins.
> 

(that was the original idea, but I would lower it today to:)
possibly, the tweaking could also be in forrest-specific 
components that are addressed from the sitemap, maybe that sounds 
less overwhelming and 'revolution' to the more hard-line 
cocooners here
(to some the sitemap is like the Arabic Sharia :-))

> Sounds cool, as long as users can still edit the sitemap directly. No

I think this very feature offers a strong reason against 
generating it?

unless you want the hastle of merging with user-customizations 
and the like :-S

There once was the idea to enable end-user sitemap customizations 
through mounted sitemaps though...

> matter how much project-specific info the siteplan captures, there will
> always be users needing to play with the sitemap directly.
> 
> What I'd like to do is write some code which, given a set of patterns:
> 
> *.pdf
> manual/*.pdf
> **/*.pdf
> 
> can sort them by 'generality'. Then we can have an Ant task which can build a
> sitemap from a bunch of sitemap snippets. Currently, the sitemap is very
> confusing, because matchers cannot be grouped by function; they must be ordered
> by increasing generality. Getting the order wrong leads to hard-to-debug
> problems. If, instead of a monolithic sitemap.xmap, we could have a bunch of
> sitemap snippets which are assembled at runtime, then a) the sitemap's
> functionality would be modular, b) users could add their snippets without
> editing (and potentially breaking) a giant confusing sitemap.
> 

sounds good, but needs some elaboration though...

and again, maybe solving it with less ant and more new cocoon 
components would probably also solve it, and be more welcomed?
- Smarter components could also be a way to cleanup the sitemap? 
(like the CAP effort?)
- A generated sitemap is probably not something one will like to 
edit manually, and as you mentioned 'some' will always like to do 
that?
- Solving with components means you get to code (and maintain) 
Java, solving it through sitemap and ant generation (like bot 
does) is more the path of writing (and maintaining XSLT :-()


or am I misenterpreting and generalizing some senses and guesses 
I just _think_ I have picked up?

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message