KISS

[Laurian Gridinoc <do...@thedot.net>]

Hi to all survivors there :)

I hate the KISS principle - I believe if a thing is complicated enough it
will be simplier... :)

Now the sitemap will ease the maintenance of an site Cocoon-based, but i
want something more complicated, i will try to write what is in my head,
those are raw ideas, please feedback on...

Let's say that i have a site... I see it as an tree of objects, each object
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, ...], i
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 can
be inherited or it will link back to the parent, and also the content can
include pieces from other objects in the tree

eventually this object it will get an mount point somehow linked to the
parent's, or it will be specified/overwrite by the creator

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

having things spread on that tree, an object must be viewd from the root,
having its path, we will pass through each node in its path to it, to obtain
it.

ignoring now the sitemap, or consicdering that this tree is the sitemap, an
request to the object will pass through each node to the object building it,
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 more
rewriting of "what was requested" in the descendant
[i'm thinking at an POST that would eventually be handled in the parent of
the object to who was the POST addressed]

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 for
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 piece
will generate in A the link to B and can contain state information about B

example:
in page A [page being the response of A to GET] there must be a image that
will link to B [B being an chatroom], this link willl have state information
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 the
fact that the user that accessed A is not registered [B "will see" that who
requested A has no required info in a cookie]

wow,
do i make any sense?

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

Re: KISS

[Laurian Gridinoc <do...@thedot.net>]

> 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
object
> > 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, ...],
i
> > 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
can
> > be inherited or it will link back to the parent, and also the content
can
> > 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
root,
> > having its path, we will pass through each node in its path to it, to
obtain
> > it.
> >
> > ignoring now the sitemap, or consicdering that this tree is the sitemap,
an
> > request to the object will pass through each node to the object building
it,
> > 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
more
> > rewriting of "what was requested" in the descendant
> > [i'm thinking at an POST that would eventually be handled in the parent
of
> > 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
it...

> > 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
for
> > 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
piece
> > will generate in A the link to B and can contain state information about
B
> >
> > example:
> > in page A [page being the response of A to GET] there must be a image
that
> > will link to B [B being an chatroom], this link willl have state
information
> > 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
the
> > fact that the user that accessed A is not registered [B "will see" that
who
> > 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
thedot.net, Inc.
www.thedot.net
--
Hell is empty and all the devils are here.
  -- Shakespeare, "The Tempest"

Re: KISS

[Stefano Mazzocchi <st...@apache.org>]

Laurian Gridinoc wrote:
> 
> Hi to all survivors there :)
> 
> I hate the KISS principle - I believe if a thing is complicated enough it
> will be simplier... :)

???
 
> Now the sitemap will ease the maintenance of an site Cocoon-based, but i
> want something more complicated, i will try to write what is in my head,
> those are raw ideas, please feedback on...

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.
 
> Let's say that i have a site... I see it as an tree of objects, each object
> 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, ...], i
> 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 can
> be inherited or it will link back to the parent, and also the content can
> 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...
 
> 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.
 
> having things spread on that tree, an object must be viewd from the root,
> having its path, we will pass through each node in its path to it, to obtain
> it.
> 
> ignoring now the sitemap, or consicdering that this tree is the sitemap, an
> request to the object will pass through each node to the object building it,
> 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 more
> rewriting of "what was requested" in the descendant
> [i'm thinking at an POST that would eventually be handled in the parent of
> the object to who was the POST addressed]

??? sorry, I can't follow you...
 
> 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 for
> 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 piece
> will generate in A the link to B and can contain state information about B
> 
> example:
> in page A [page being the response of A to GET] there must be a image that
> will link to B [B being an chatroom], this link willl have state information
> 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 the
> fact that the user that accessed A is not registered [B "will see" that who
> 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.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------