You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Michael Wechner <mi...@wyona.org> on 2003/09/20 00:44:03 UTC

Syncato

On Sam Ruby's Blog I have read about Syncato. It's all XML and XSLT, so 
some of you might be interested in
to take a look at it:

http://www.syncato.org

Thanks

Michael


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


RE: Syncato

Posted by Robert Koberg <ro...@koberg.com>.
Hi,

> -----Original Message-----
> From: Gregor J. Rothfuss [mailto:gregor@apache.org]
> Sent: Sunday, September 21, 2003 8:31 AM
> To: Lenya Developers List
> 
> Michael Wechner wrote:
> 
> > http://www.syncato.org
> 
> what i like best about this is:
> 
> "In reality Syncato is much more then just a weblog system, it's an XML
> fragment management system."
> 
> lenya is targetted towards management of complete xml documents. it
> could learn a lot from syncato in the area of fragments. use cases would
>   be
> 
> - micropublishing
> - related content
> - content reuse
> - fuzzy search
> 
> kimbro is the co-founder of xindice, btw:
> 
> http://www.xmldatabases.org/movabletype/archives/000016.html
> 
> i have always wondered when the time for moving beyond xml & xslt
> towards xquery, xupdate and xpath would be. to do interesting queries
> with xml requires a good amount of existing xml data, which may now be
> the case. maybe it is time for looking at xml fragments?
> 
> just some RT


Yes, but it is not really new. This is something that can be stored in a
'site.xml' (I see you have an RFC for this). I would like to offer/propose
you guys utilize our way of doing the site.xml (snippet below) with a Lenya
namespace, of course. I can provide you with an XML Schema and some
JavaScript objects for tree manipulation. I can also give you a basic set of
XSL that uses the site.xml to transform pages.

I tried to get this adopted in the forrest project, which it was in a way,
but in a different direction which I feel is very limited in several ways.

This is related to the RT in that XML fragments are referenced in //(page |
folder | site)/regions/region. The region name identifies an HTML DIV (in
our case) or what-have-you. Content assigned to folders cascades down to the
pages in that folder.

In addition you will notice that some useful metadata/attributes are on the
site, folder and page nodes. Hopefully they are meaningful. If not please
ask for clarification.

If stored in an XMLDB that has XUpdate capabilities you can let the user
edit page/folder/etc 'properties', PUT it to the server as XML and update
the DB. Users can go to a gui view of a content repository and assign
content to regions in a page or folder and submit it to be updated on the
server.

The site.xml is used as the main XML Source in a transformation. Doing this
allows for any internal links to always be valid no matter how often the
site architecture is rearranged (this could solve the doc problem that
cocoon devs are currently experiencing). The metadata tells the
transformation things like: should the pages in a folder show a
snailtrail/pager, should a page show on the nav, should the page be
generated, should it have a print friendly page, etc.

To generate a site instance (the site.xml is a virtual representation of a
site), simply run the site.xml through some kind of ContentHandler that
creates the folders and transforms the pages. The one I am currently using
generates a 100 page site (with html print friendlies, external metadata) in
about 4-5 seconds.

What I have been working on recently is having XMLFilters strip out
unnecessary attributes except for those on the site, parent folder and
target page nodes for a transformation. In one of the filters something like
XInclude replaces the regions/region/item/@ref with the XML instance it
refers to.

I currently keep the site.xml unmarshalled into a JDOM Document and
manipulate it with JDOM methods. The XML fragments are brought in during the
transformation using the XSL document function. I would like to replace this
with a full SAX approach and XInclude.

Is this interesting at all?

Best,
-Rob

Here is a snippet of our site.xml for the liveSTORYBOARD site:

<lsb:site css="default.css" id="wwwuser" index_page="p1395893912" onnav="0"
xsl="xsl_default"
xmlns:lsb="http://livestoryboard.com/lsb/schemas/2003/03/config">
  <lsb:label>Home</lsb:label>
  <lsb:title>liveSTORYBOARD</lsb:title>
  <lsb:page css="inherit" generate="1" id="p1395893912" name="Welcome.html"
onnav="1" pgstatus="publish" print_friendly="0" xsl="xsl_homepage">
    <lsb:label>Home</lsb:label>
    <lsb:title>liveSTORYBOARD Content Management System: Simple, powerful
and secure hosted Web Content Management</lsb:title>
    <lsb:regions>
      <lsb:region name="wide_col">
        <lsb:item ref="a1095201465"></lsb:item>
        <lsb:item ref="c404932357"></lsb:item>
      </lsb:region>
      <lsb:region name="narrow1_col">
        <lsb:item ref="c1109515213"></lsb:item>
        <lsb:item ref="c108879656"></lsb:item>
      </lsb:region>
    </lsb:regions>
  </lsb:page>
  <lsb:folder css="inherit" expand="0" id="f61944265" name="Products"
onnav="1" pager="0" snailtrail="1" xsl="inherit" index_page="p259623336">
    <lsb:label>Products</lsb:label>
    <lsb:title>liveSTORYBOARD CMS: Simple, powerful and secure Web Content
Management</lsb:title>
    <lsb:page css="inherit" generate="1" id="p888519293"
name="For_management.html" onnav="0" pgstatus="publish" print_friendly="1"
xsl="inherit">
      <lsb:label>For management</lsb:label>
      <lsb:title>liveSTORYBOARD CMS: Content Management Information for
Management</lsb:title>
      <lsb:regions>
        <lsb:region name="wide_col">
          <lsb:item ref="c345381544"></lsb:item>
          <lsb:item ref="c282131128"></lsb:item>
          <lsb:item ref="c23518570"></lsb:item>
          <lsb:item ref="c1148983184"></lsb:item>
        </lsb:region>
        <lsb:region name="narrow1_col">
          <lsb:item ref="c1408111999"></lsb:item>
          <lsb:item ref="c1845444322"></lsb:item>
        </lsb:region>
      </lsb:regions>
    </lsb:page>


> 
> -gregor
> 
> --
> Gregor J. Rothfuss
> Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
> http://wyona.com                   http://cocoon.apache.org/lenya
> gregor.rothfuss@wyona.com                       gregor@apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: lenya-dev-help@cocoon.apache.org


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


Re: Syncato

Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Michael Wechner wrote:

> http://www.syncato.org

what i like best about this is:

"In reality Syncato is much more then just a weblog system, it's an XML 
fragment management system."

lenya is targetted towards management of complete xml documents. it 
could learn a lot from syncato in the area of fragments. use cases would 
  be

- micropublishing
- related content
- content reuse
- fuzzy search

kimbro is the co-founder of xindice, btw:

http://www.xmldatabases.org/movabletype/archives/000016.html

i have always wondered when the time for moving beyond xml & xslt 
towards xquery, xupdate and xpath would be. to do interesting queries 
with xml requires a good amount of existing xml data, which may now be 
the case. maybe it is time for looking at xml fragments?

just some RT

-gregor

-- 
Gregor J. Rothfuss
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://wyona.com                   http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com                       gregor@apache.org


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