cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Laurian Gridinoc" <>
Subject Re: KISS
Date Mon, 03 Jan 2000 07:48:52 GMT
> I was waiting for comments like "how can I possibly manage the sitemap
> of my site?", no "this is too easy, give me more" :) Impressive.

now, the sitemap is not so easy , but it seems to be so :)
what i say here is in a way different that the sitemap in discussion, is
just a strange idea i had

> > Let's say that i have a site... I see it as an tree of objects, each
> > has its XML, XSL and so on, and each object can be mounted through the
> > sitemap thing.
> >
> > But, I want more:
> >
> > A new page -  i will create a new object somewhere in the tree, this new
> > object will inherit the properties of the parent [style, content, ...],
> > would eventually rewrite some of them - like change the style a bit in
> > couple places,... i'm not sure how this can be done... same the content
> > be inherited or it will link back to the parent, and also the content
> > include pieces from other objects in the tree
> Hmmm, part of this can already be done. We define URI areas that all go
> thru the same processing chain and all have the same processing
> parameters. So, if you place your new page into a URI area, you don't
> have to touch the sitemap: Cocoon will already know how to handle it.
> On some other points, I humbly think you are loosing your focus on the
> problem...

You probably are right. [on the focus]
Those were just raw thought on how I would see an site...
I like the idea that a page would "extend" another.

> > eventually this object it will get an mount point somehow linked to the
> > parent's, or it will be specified/overwrite by the creator
> The sitemap is the blueprint for site linking. Cocoon only deals with
> links on the soft/hard way, but it's up to the content creators to
> design and create the links. Why? because links belong to the content
> context.
> > so, if i change something in the style/content in an object, this change
> > will be inherited by all the descendants if they don't rewrite it
> No way. You're thinking about a tree system, but topologically, this is
> a graph. In a graph, every node can be a descendant of another.

I know, i'm tring to think at it like a tree, and later as a graph, i'm just
seeking the dream of inheritance to smooth page creation/management...
because i have to make tools on it to let my XML-ignorant designer touch the
sites.. :(

> > having things spread on that tree, an object must be viewd from the
> > having its path, we will pass through each node in its path to it, to
> > it.
> >
> > ignoring now the sitemap, or consicdering that this tree is the sitemap,
> > request to the object will pass through each node to the object building
> > a request could mean more than GET, each node that "is in the way" can
> > reroute that request according to http headers stuff [user agent,
> > cookies,...], or it can "stop" the request and handle it if there is no
> > rewriting of "what was requested" in the descendant
> > [i'm thinking at an POST that would eventually be handled in the parent
> > the object to who was the POST addressed]
> ??? sorry, I can't follow you...
let me think what i wanted to say... :)
is tree-based :(, but the idea is that what a page is made of [XML/XSL/...]
is spread on the path to the leaf that represents the final page...
[each node exptends its parent, changing(redefining) small things]
each node can be or not opaque to a request type [handle it or let it pass
to the next node]

i got that idea seeing how my designer was "doing" sites in photoshop,
adding several layers [which could change only the style or the content]
over the homepage image to make the look of the anothe page...
he 'extended' the homepage...
ant this reminded me of Photon windowing system in QNX OS...
we can have a page - as a result of overlaping several layers [read
pages] -- the process will start from the root to the leaf... i have to draw

> > also, the links between objects [i mean hrefs] could be complicated :)
> > the object A must link to B, in order to do so, the object A request B
> > linking, B would return just an URL [mount point in sitemap], or B could
> > return an piece of html/xml whatever will be the processing ... - this
> > will generate in A the link to B and can contain state information about
> >
> > example:
> > in page A [page being the response of A to GET] there must be a image
> > will link to B [B being an chatroom], this link willl have state
> > to B: the alt attribute will say: "there is no one in the chatroom right
> > now"; eventually the href will point to an different URL according with
> > fact that the user that accessed A is not registered [B "will see" that
> > requested A has no required info in a cookie]
> >
> > wow,
> > do i make any sense?
> Honest? not much :) please, try again, it's probably just me, but I'm
> very interested in other ideas about the sitemap.

I will try to draw how i see the whole thing on a tree, if on a tree the
idea will proove to be interesting i will think at graph...

Laurian Gridinoc
Chief Technology Officer, Inc.
Hell is empty and all the devils are here.
  -- Shakespeare, "The Tempest"

View raw message