You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ross Gardler <rg...@apache.org> on 2005/06/28 14:31:00 UTC
Eclipse based site.xml editor (Re: Requesting Comments on Eclipse
Plugin Deliverables)
Anil Ramnanan wrote:
> Ross Gardler wrote:
>
>>
>> +1 - Anil this can be removed without any impact on the completeness of
>> your project, if we get time, and the discussion has been settled then
>> we will address this.
>>
> I will remove it. The first thing I would like to work on is the Site
> editor. I had intended to do this using the Eclipse Modelling Framework
> if there was and XML schema for the sitemap available. Otherwise I will
> have to do a normal tree editor. Any comments ?
The sitemap and site.xml are two different things. The sitemap describes
how Forrest should process requests - see
You will not be building an editor for this since the Lepido project
already has one (I checked this morning their code is now in CVS, but it
has not been publically announced yet).
Site.xml describes the structure the site, i.e. what files go where.
There is no DTD for this file, we have discussed having one on occasion,
but at present there isn't one. Since there is no DTD you have two choices:
a) start a discussion about whether we want one or not
b) go with a basic tree widget and ensure it creates valid XML
However, before doing that we really need to decide what the editor will
look like as this will have an impact on the way you implement it. I see
there being two options:
+------------+----------------------------------------------+
| | +
| | +
| File | +
| Navigator | Page Editor +
| | +
| | +
| | +
+------------+----------------------------------------------+
| | +
| | +
| Site | +
| Editor | Properties Editor +
| | +
| | +
| | +
+------------+----------------------------------------------+
Here we have easy drag and drop between the file navigator and we can
quickly switch the page being edited by clicking on the site editor. It
will also allow us to quickly see a preview of the site structure when
it is edited. However, we are limiting the space available for the file
navigator and site editor.
+------------+----------------------------------------------+
| | +
| | +
| File | +
| Navigator | Page * site Editor +
| | +
| | +
| | +
| +----------------------------------------------+
| | +
| | +
| | +
| | Properties Editor +
| | +
| | +
| | +
+------------+----------------------------------------------+
Here the page/site editor is a tabbed editor, one tab providing access
to the site structure, the other providing access to the page contents.
This set-up will increase the number of clicks needed to find/add a page
in the site editor but it will allow more control over what the site
editor looks like.
Note for technical reasons with Eclipse it is not possible to have an
editor that will appear in both the views section (i.e. the left or
bottom of the application) and the editor section (i.e. the top right in
the above diagrams).
Personally I prefer the first method. However, the EMF will not create
the view we need to do this. In Burrokeet I have tweaked the code to
allow this to happen. However, I would not recomend doing that, it has
caused all sorts of problems for us. In other words, if you go with the
first route then I would recomend building a custom viewer.
Do others have any opinion on the best layout?
Ross
Re: ASF Standard for site.xml aka sitetree.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Gregor J. Rothfuss wrote:
...
> i suppose you could do:
>
> <menu name="Maven 2.0">
> <!-- this is the menu -->
> <item id="intro" name="Introduction" href="index.html"/>
> <item id="download" name="Download" href="download/">
> <item id="1-4" name="1.4" href="1.4.html">
> <item xml:lang="en" id="1-2" name="1.2" href="1.2.en.html">
> <item xml:lang="de" id="1-2" name="1.2" href="1.2.de.html">
> <item visibleinnav="false" name="Road Map" href="roadmap.html" />
> </menu>
>
> in essence, augment the maven format with additional attributes as
> required.
Yes, that's it :-)
Just one thing: visibleinnav="false"... in Forrest we just delete the
@name to make it invisible...
> i suppose maven does not validate site.xml?
That's not so important, as they could do so easily if they want to be
able to render Forrest or Lenya sites. The goal is to not make a
completely different format just for the sake of it.
In any case, xml-lang is another namespace, and the id IIRC can always
be there, so probably it would still validate.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: ASF Standard for site.xml aka sitetree.xml
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Nicola Ken Barozzi wrote:
>>> I would be even more supportive if Lenya and Cocoon adopt the Maven one,
>>> so that we would have a single format for all these projects.
>> You mean http://maven.apache.org/maven2/site.html ?
> And here is how we could do it instead:
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <project name="Maven">
> <body>
> <links>
> <!-- these are the tabs -->
>
> <item id="apache" name="Apache" href="http://www.apache.org/" />
> <item name="Maven 1.0" href="http://maven.apache.org/"/>
> </links>
>
> <menu name="Maven 2.0">
> <!-- this is the menu -->
>
> <item id="intro" name="Introduction" href="index.html"/>
> <item id="download" name="Download" href="download.html"/>
> <item name="Road Map" href="roadmap.html" />
> </menu>
>
> ...
> </body>
> </project>
that in itself would not be sufficient. i suppose you could do:
<menu name="Maven 2.0">
<!-- this is the menu -->
<item id="intro" name="Introduction" href="index.html"/>
<item id="download" name="Download" href="download/">
<item id="1-4" name="1.4" href="1.4.html">
<item xml:lang="en" id="1-2" name="1.2" href="1.2.en.html">
<item xml:lang="de" id="1-2" name="1.2" href="1.2.de.html">
<item visibleinnav="false" name="Road Map" href="roadmap.html" />
</menu>
in essence, augment the maven format with additional attributes as
required. i suppose maven does not validate site.xml?
Re: ASF Standard for site.xml aka sitetree.xml (was Re: Eclipse based
site.xml editor)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Thorsten Scherler wrote:
> On Wed, 2005-06-29 at 08:43 +0200, Nicola Ken Barozzi wrote:
...
>>I would be even more supportive if Lenya and Cocoon adopt the Maven one,
>>so that we would have a single format for all these projects.
>
> You mean http://maven.apache.org/maven2/site.html ?
>
> The section "Creating a Site Descriptor" has an example.
Yes, although we don't need to use all tags and can add others if we
wish so.
Here is the example:
<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="Maven">
<bannerLeft>
<name>Maven</name>
<src>http://maven.apache.org/images/apache-maven-project.png</src>
<href>http://maven.apache.org/</href>
</bannerLeft>
<bannerRight>
<src>http://maven.apache.org/images/maven-small.gif</src>
</bannerRight>
<body>
<links>
<item name="Apache" href="http://www.apache.org/" />
<item name="Maven 1.0" href="http://maven.apache.org/"/>
<item name="Maven 2" href="http://maven.apache.org/maven2/"/>
</links>
<menu name="Maven 2.0">
<item name="Introduction" href="index.html"/>
<item name="Download" href="download.html"/>
<item name="Release Notes" href="release-notes.html" />
<item name="General Information" href="about.html"/>
<item name="For Maven 1.0 Users" href="maven1.html"/>
<item name="Road Map" href="roadmap.html" />
</menu>
${reports}
...
</body>
</project>
And here is how we could do it instead:
<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="Maven">
<body>
<links>
<!-- these are the tabs -->
<item id="apache" name="Apache" href="http://www.apache.org/" />
<item name="Maven 1.0" href="http://maven.apache.org/"/>
<item name="Maven 2" href="http://maven.apache.org/maven2/"/>
</links>
<menu name="Maven 2.0">
<!-- this is the menu -->
<item id="intro" name="Introduction" href="index.html"/>
<item id="download" name="Download" href="download.html"/>
<item name="Release Notes" href="release-notes.html" />
<item name="General Information" href="about.html"/>
<item name="For Maven 1.0 Users" href="maven1.html"/>
<item name="Road Map" href="roadmap.html" />
</menu>
...
</body>
</project>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: ASF Standard for site.xml aka sitetree.xml (was Re: Eclipse based
site.xml editor)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Wed, 2005-06-29 at 08:43 +0200, Nicola Ken Barozzi wrote:
>
>>Ross Gardler wrote:
>>
>>>Gregor J. Rothfuss wrote:
>>>
>>>
>>>>Ross Gardler wrote:
...
>>>> The current practice is that if we need a valid site
>>>structure document then we simply create a internal plugin (like the
>>>IMSManifest plugin) for it.
...
>>I would be even more supportive if Lenya and Cocoon adopt the Maven one,
>>so that we would have a single format for all these projects.
If you want any site navigation format other than site.xml then simply
write an Internal plugin for it. To see how see the IMSManifest plugin.
There is no need for discussion since the plugin will be entirely optional.
Speaking personally I have no use cases that are not well supported by
one of the two existing options. IMS Manifest is extremely powerful and
is a standard, site.xml is extremely simple and flexible, as well as
offering things like site: and ext:
If someone implements a new site structure plugin then we can talk about
making it "the standard", but until then discussion is pointless, we've
done it many times before. The conclusion was always "yeah there are
some good reasons to change and some good reasons not to change", nobody
has yet had a strong enough itch to build the alternative plugins. I
encourage someone to do that, lets increase the options.
For Anils work he needs to get started so I think it is best he builds
the site.xml editor. We can always change the XML structure it outputs
at a later date if necessary.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
ASF Standard for site.xml aka sitetree.xml (was Re: Eclipse based
site.xml editor)
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2005-06-29 at 08:43 +0200, Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
> > Gregor J. Rothfuss wrote:
> >
> >> Ross Gardler wrote:
> >>
> >>> Well, in that case I would avoid EMF for this instance and we need
> >>> not consider whether site.xml is to have a DTD or not. Just a tree
> >>> editor with configurable properties on each node will do just fine.
> >>
> >> the completely free-form site.xml where each node can have pretty much
> >> any element name doesn't lend itself to a schema / DTD easily. maybe
> >> it would be useful to revisit that decision and switch to a system
> >> where you have
> >>
> >> <node id="uniqueid" href="index.html" label="About"/>
> >>
> >> this would also enforce that each node has a unique id and is
> >> therefore addressable by site:uniqueid
> >>
> >> WDYT?
> >
> > I think we discussed this to death already ;-)
> >
> > There are good reasons for us not doing that (all related to the site:
> > protocol if I remember correctly). There have been a few proposals for a
> > DTD but none have had a strong enough use case to warrant us disabling
> > the site: protocol. The current practice is that if we need a valid site
> > structure document then we simply create a internal plugin (like the
> > IMSManifest plugin) for it.
> >
> > Of course, no such decision is ever final. If someone wants to go
> > through the archives and make a new proposal we'll consider it.
>
> Ok, here it comes :-)
>
> One thing is the *internal* representation, that must be kept as now
> because of the way the site: protocol works. But this does not mean that
> we cannot decide to make the _default_ external representation be different.
>
> Personally, I would support we change the default external
> representation to something akin to what Gregor proposes, and in
> particular the same as the Lenya one.
>
> I would be even more supportive if Lenya and Cocoon adopt the Maven one,
> so that we would have a single format for all these projects.
>
You mean http://maven.apache.org/maven2/site.html ?
The section "Creating a Site Descriptor" has an example.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
ASF Standard for site.xml aka sitetree.xml (was Re: Eclipse based
site.xml editor)
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2005-06-29 at 08:43 +0200, Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
> > Gregor J. Rothfuss wrote:
> >
> >> Ross Gardler wrote:
> >>
> >>> Well, in that case I would avoid EMF for this instance and we need
> >>> not consider whether site.xml is to have a DTD or not. Just a tree
> >>> editor with configurable properties on each node will do just fine.
> >>
> >> the completely free-form site.xml where each node can have pretty much
> >> any element name doesn't lend itself to a schema / DTD easily. maybe
> >> it would be useful to revisit that decision and switch to a system
> >> where you have
> >>
> >> <node id="uniqueid" href="index.html" label="About"/>
> >>
> >> this would also enforce that each node has a unique id and is
> >> therefore addressable by site:uniqueid
> >>
> >> WDYT?
> >
> > I think we discussed this to death already ;-)
> >
> > There are good reasons for us not doing that (all related to the site:
> > protocol if I remember correctly). There have been a few proposals for a
> > DTD but none have had a strong enough use case to warrant us disabling
> > the site: protocol. The current practice is that if we need a valid site
> > structure document then we simply create a internal plugin (like the
> > IMSManifest plugin) for it.
> >
> > Of course, no such decision is ever final. If someone wants to go
> > through the archives and make a new proposal we'll consider it.
>
> Ok, here it comes :-)
>
> One thing is the *internal* representation, that must be kept as now
> because of the way the site: protocol works. But this does not mean that
> we cannot decide to make the _default_ external representation be different.
>
> Personally, I would support we change the default external
> representation to something akin to what Gregor proposes, and in
> particular the same as the Lenya one.
>
> I would be even more supportive if Lenya and Cocoon adopt the Maven one,
> so that we would have a single format for all these projects.
>
You mean http://maven.apache.org/maven2/site.html ?
The section "Creating a Site Descriptor" has an example.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Eclipse based site.xml editor (Re: Requesting Comments on Eclipse
Plugin Deliverables)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
> Gregor J. Rothfuss wrote:
>
>> Ross Gardler wrote:
>>
>>> Well, in that case I would avoid EMF for this instance and we need
>>> not consider whether site.xml is to have a DTD or not. Just a tree
>>> editor with configurable properties on each node will do just fine.
>>
>> the completely free-form site.xml where each node can have pretty much
>> any element name doesn't lend itself to a schema / DTD easily. maybe
>> it would be useful to revisit that decision and switch to a system
>> where you have
>>
>> <node id="uniqueid" href="index.html" label="About"/>
>>
>> this would also enforce that each node has a unique id and is
>> therefore addressable by site:uniqueid
>>
>> WDYT?
>
> I think we discussed this to death already ;-)
>
> There are good reasons for us not doing that (all related to the site:
> protocol if I remember correctly). There have been a few proposals for a
> DTD but none have had a strong enough use case to warrant us disabling
> the site: protocol. The current practice is that if we need a valid site
> structure document then we simply create a internal plugin (like the
> IMSManifest plugin) for it.
>
> Of course, no such decision is ever final. If someone wants to go
> through the archives and make a new proposal we'll consider it.
Ok, here it comes :-)
One thing is the *internal* representation, that must be kept as now
because of the way the site: protocol works. But this does not mean that
we cannot decide to make the _default_ external representation be different.
Personally, I would support we change the default external
representation to something akin to what Gregor proposes, and in
particular the same as the Lenya one.
I would be even more supportive if Lenya and Cocoon adopt the Maven one,
so that we would have a single format for all these projects.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Eclipse based site.xml editor (Re: Requesting Comments on Eclipse
Plugin Deliverables)
Posted by Ross Gardler <rg...@apache.org>.
Gregor J. Rothfuss wrote:
> Ross Gardler wrote:
>
>> Well, in that case I would avoid EMF for this instance and we need not
>> consider whether site.xml is to have a DTD or not. Just a tree editor
>> with configurable properties on each node will do just fine.
>
>
> the completely free-form site.xml where each node can have pretty much
> any element name doesn't lend itself to a schema / DTD easily. maybe it
> would be useful to revisit that decision and switch to a system where
> you have
>
> <node id="uniqueid" href="index.html" label="About"/>
>
> this would also enforce that each node has a unique id and is therefore
> addressable by site:uniqueid
>
> WDYT?
I think we discussed this to death already ;-)
There are good reasons for us not doing that (all related to the site:
protocol if I remember correctly). There have been a few proposals for a
DTD but none have had a strong enough use case to warrant us disabling
the site: protocol. The current practice is that if we need a valid site
structure document then we simply create a internal plugin (like the
IMSManifest plugin) for it.
Of course, no such decision is ever final. If someone wants to go
through the archives and make a new proposal we'll consider it.
Ross
Re: Eclipse based site.xml editor (Re: Requesting Comments on Eclipse
Plugin Deliverables)
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Ross Gardler wrote:
> Well, in that case I would avoid EMF for this instance and we need not
> consider whether site.xml is to have a DTD or not. Just a tree editor
> with configurable properties on each node will do just fine.
the completely free-form site.xml where each node can have pretty much
any element name doesn't lend itself to a schema / DTD easily. maybe it
would be useful to revisit that decision and switch to a system where
you have
<node id="uniqueid" href="index.html" label="About"/>
this would also enforce that each node has a unique id and is therefore
addressable by site:uniqueid
WDYT?
Re: Eclipse based site.xml editor (Re: Requesting Comments on Eclipse
Plugin Deliverables)
Posted by Ross Gardler <rg...@apache.org>.
Anil Ramnanan wrote:
> Ross Gardler wrote:
>
>>
>> Here we have easy drag and drop between the file navigator and we can
>> quickly switch the page being edited by clicking on the site editor.
>> It will also allow us to quickly see a preview of the site structure
>> when it is edited. However, we are limiting the space available for
>> the file navigator and site editor.
>>
>>
> I prefer this method. Even if you needed more space like the second
> version, you can always move the views around witin Eclipse to make more
> space.
Well, in that case I would avoid EMF for this instance and we need not
consider whether site.xml is to have a DTD or not. Just a tree editor
with configurable properties on each node will do just fine.
Ross
Re: Eclipse based site.xml editor (Re: Requesting Comments on Eclipse
Plugin Deliverables)
Posted by Anil Ramnanan <li...@peppersauce.org>.
Ross Gardler wrote:
>
> Here we have easy drag and drop between the file navigator and we can
> quickly switch the page being edited by clicking on the site editor.
> It will also allow us to quickly see a preview of the site structure
> when it is edited. However, we are limiting the space available for
> the file navigator and site editor.
>
>
I prefer this method. Even if you needed more space like the second
version, you can always move the views around witin Eclipse to make more
space.
Anil.