You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by "Gav...." <br...@brightontown.com.au> on 2006/01/18 13:39:21 UTC
Example use case.
Not sure the subject is contradictory but anyway ...
I find it easier to understand things by doing. I am finding I am
still having a problem grasping some parts of forrest .... and
then v3 comes along! (Thanks Thorsten :) ) .
Anyway, as I have no use case and no real need for forrest, I see
this as my downfall - no real life motivation to crack on with it. I
just stumble around here and there, picking things up. So, I made
up a use case and so now then I 'really need' v3 to work - I know
it is still early days etc etc, but its what I want so...
Ok, so I have a site I have been throwing stuff into now and then, the
forums seem to be getting more popular, as are the stats steadily
rising. So I'd like to use forrest on it now.
The site in question is http://www.minitutorials.com . As a little
background,
the site is xhtml1.1 compliant (mostly, and that negotiable - but to give
you
an idea of the standard of code). The left nav is 'included' into the site
via
a php require as is the right hand side column. The site is constructed as
expected these days using CSS for layout and not a table in sight.
To the point, how do I now convert this site to use Forrest , v3 if possible
but
earlier if it illustrates it better to me.
David C prompted me into this inadvertantly with his HTML conversions of
Incubator to Anakia. Do I have to manually re-write all of my sites .html or
.php pages into xml source files or can I do this another way. Ah, theres
something, most of my pages are PHP, does that make a difference. If it
does, I'll get rid of them I dont care, theres not much PHP code that I cant
do another way (or get rid).
Then, looking at the site, can I then use CSS or whatever to somewhere near
resemble what I have currently or not - again, I don't care, its a useful
site, but
hardly earth-shattering and could probably do with a makeover anyway - which
when forrest-enabled I could do as often as I like with new themes right?
After all this, maybe then I can be of more use to the community rather than
sending patches in that no-one else wants to do. (Even Incubator with its
massive load of 13 Issues seems to not want them)
Yada
Gav...
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.20/233 - Release Date: 18/01/2006
Re: [zone] httpd configuration (was character entities)
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> David Crossley escribi??:
> > Thorsten Scherler wrote:
> > > David Crossley escribi??:
> > > >
> > > > No need to have them all in SVN, just the one that
> > > > we want to change.
> > > >
> > > > I see that Cocoon put all their config into the
> > > > pmc/cocoon section of the private committers svn.
> > >
> > > Hmm, and how are they doing the checkout?
> >
> > At the moment it is actually the other way around.
> > They maintain the files on the server, and a tar-it-up.sh
> > to gather the important files, then a committer unpacks
> > and adds it to svn. A temporary measure.
>
> Hmm, yeah a route that we should not go.
However it might make sense for these few
secret files, to get around the problem that
you describe below.
> > > I thought the private stuff is
> > > with password and we cannot checkout stuff with a user on zones.
> >
> > As long as the user is in the right group
> > it will be fine. And as long as each user sets
> > their umask properly.
>
> Hmm, you know that svn stores the password in a file? This means at
> least sudo can look up all passwords if she wants.
I see what you mean. However our committers
are trusted and people only get sudo if they
need it. Still you are right.
I wonder how other projects do it.
Perhaps a question for infra@.
Actually all the svn checkouts that i have
done on the zone are anonymous checkouts,
i.e. http and not https, so no password.
However, that will not work for our section
of the committers repository.
> I thought that was
> the reason why we could not set up a forrestbot on zones that is
> actually as well deploying to our website. ???
Not really. The reason is that we cannot
use a role-based account to do svn checkin.
i.e. imagine that we wanted to have a special
user called 'fb' and use that to run forrestbot
and do 'svn ci'. We cannot because 'fb' is not
a committer and so has no credentials.
> > That module is private to "committers" so that
> > should be okay.
>
> Yeah, still the password is stored on the server.
>
> > > > We should do the same for sensitive files like httpd.conf
> > > >
> > > > The main stuff would stay in our forrest/zones svn,
> > > > because that is not sensitive and is of use to
> > > > other people.
> > >
> > > Agree but I am not sure how you thought about it.
> >
> > Neither am i.
>
> ;-)
>
> > > > > > Either way, we will need a document to remind us of all about
> > > > > > these specific symlinks and 'svn co'. I started something at
> > > > > > f.a.o/zone.html
> > > > >
> > > > > I have not checked it in yet because we should decide first whether we
> > > > > want to have /etc/apache2/ in our svn or only /etc/apache2/httpd.conf.
> > > > >
> > > > > I added it for now directly to /etc/apache2/httpd.conf and started the
> > > > > server (which had been down).
> > > >
> > > > Glad that more people can now start the services.
> > > > We need to listen to infra@ and realise it is down.
> > >
> > > Actually I submitted a patch to infrastructure to monitor lenya.zones
> > > with http://monitoring.apache.org/status/
> > >
> > > http://issues.apache.org/jira/browse/INFRA-698
> > >
> > > If we want, I can do the same for forrest, then we know when it is down
> > > and can react.
> >
> > Our http server should only be down if the whole
> > zones machine has been rebooted. So IMO no need
> > for monitoring.
>
> I have set up (again) a lenya instance on
> http://lenya.zones.apache.org/index.html for us a while ago. I have not
> told anyone till now because I hoped that my infra patch will be applied
> and we could monitor the server right away. I did some testing with up
> times and it seems to be fine this time.
> http://lenya.zones.apache.org:9000/
>
> But actually I would like to propose to set up a lenya instance on *our*
> zones server (due to the fact that I am the only one in lenya ATM that
> is looking out for the zone, it does not make any different to me to
> support it directly here). I am keen that we slowly playing around with
> lenya as cms and that we are independent from the lenya zone.
Better propose that in a separate thread.
Sounds like a good idea. That way other Forrest
committers can help.
> Further I would like to see as well a dynamic instance of forrest
> running on zone (I plan to start a web gui for dynamically altering
> structurer files) as show case.
We need to first make sure that forrest is
not a resource hog. This zone machine is shared
with other users, and we don't want to get
a bad name.
> > > > Next step is to automate the startup. See the fixme
> > > > note at http://forrest.apache.org/zone.html#admin
> > >
> > > Yeah on lenya we seem to have it because you cannot stop the httpd
> > > without another one get up instantly. I will try to find the difference
> > > between both configs.
> >
> > We don't have any config. As you can see we must start by
> > hand after a reboot.
>
> I will try to set this up ASAP, since just today the server was down again (I started it again).
Okay, i presume that you mean 'smf'.
-David
Re: [zone] httpd configuration (was character entities)
Posted by Thorsten Scherler <th...@apache.org>.
El sáb, 28-01-2006 a las 22:17 +1100, David Crossley escribió:
> Thorsten Scherler wrote:
> > David Crossley escribi??:
> > >
> > > No need to have them all in SVN, just the one that
> > > we want to change.
> > >
> > > I see that Cocoon put all their config into the
> > > pmc/cocoon section of the private committers svn.
> >
> > Hmm, and how are they doing the checkout?
>
> At the moment it is actually the other way around.
> They maintain the files on the server, and a tar-it-up.sh
> to gather the important files, then a committer unpacks
> and adds it to svn. A temporary measure.
Hmm, yeah a route that we should not go.
>
> > I thought the private stuff is
> > with password and we cannot checkout stuff with a user on zones.
>
> As long as the user is in the right group
> it will be fine. And as long as each user sets
> their umask properly.
Hmm, you know that svn stores the password in a file? This means at
least sudo can look up all passwords if she wants. I thought that was
the reason why we could not set up a forrestbot on zones that is
actually as well deploying to our website. ¿?
>
> That module is private to "committers" so that
> should be okay.
Yeah, still the password is stored on the server.
>
> > > We should do the same for sensitive files like httpd.conf
> > >
> > > The main stuff would stay in our forrest/zones svn,
> > > because that is not sensitive and is of use to
> > > other people.
> >
> > Agree but I am not sure how you thought about it.
>
> Neither am i.
;-)
>
> > > > > Either way, we will need a document to remind us of all about
> > > > > these specific symlinks and 'svn co'. I started something at
> > > > > f.a.o/zone.html
> > > >
> > > > I have not checked it in yet because we should decide first whether we
> > > > want to have /etc/apache2/ in our svn or only /etc/apache2/httpd.conf.
> > > >
> > > > I added it for now directly to /etc/apache2/httpd.conf and started the
> > > > server (which had been down).
> > >
> > > Glad that more people can now start the services.
> > > We need to listen to infra@ and realise it is down.
> >
> > Actually I submitted a patch to infrastructure to monitor lenya.zones
> > with http://monitoring.apache.org/status/
> >
> > http://issues.apache.org/jira/browse/INFRA-698
> >
> > If we want, I can do the same for forrest, then we know when it is down
> > and can react.
>
> Our http server should only be down if the whole
> zones machine has been rebooted. So IMO no need
> for monitoring.
I have set up (again) a lenya instance on
http://lenya.zones.apache.org/index.html for us a while ago. I have not
told anyone till now because I hoped that my infra patch will be applied
and we could monitor the server right away. I did some testing with up
times and it seems to be fine this time.
http://lenya.zones.apache.org:9000/
But actually I would like to propose to set up a lenya instance on *our*
zones server (due to the fact that I am the only one in lenya ATM that
is looking out for the zone, it does not make any different to me to
support it directly here). I am keen that we slowly playing around with
lenya as cms and that we are independent from the lenya zone.
Further I would like to see as well a dynamic instance of forrest
running on zone (I plan to start a web gui for dynamically altering
structurer files) as show case.
>
> > > Next step is to automate the startup. See the fixme
> > > note at http://forrest.apache.org/zone.html#admin
> >
> > Yeah on lenya we seem to have it because you cannot stop the httpd
> > without another one get up instantly. I will try to find the difference
> > between both configs.
>
> We don't have any config. As you can see we must start by
> hand after a reboot.
>
I will try to set this up ASAP, since just today the server was down again (I started it again).
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [zone] httpd configuration (was character entities)
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> David Crossley escribi??:
> >
> > No need to have them all in SVN, just the one that
> > we want to change.
> >
> > I see that Cocoon put all their config into the
> > pmc/cocoon section of the private committers svn.
>
> Hmm, and how are they doing the checkout?
At the moment it is actually the other way around.
They maintain the files on the server, and a tar-it-up.sh
to gather the important files, then a committer unpacks
and adds it to svn. A temporary measure.
> I thought the private stuff is
> with password and we cannot checkout stuff with a user on zones.
As long as the user is in the right group
it will be fine. And as long as each user sets
their umask properly.
That module is private to "committers" so that
should be okay.
> > We should do the same for sensitive files like httpd.conf
> >
> > The main stuff would stay in our forrest/zones svn,
> > because that is not sensitive and is of use to
> > other people.
>
> Agree but I am not sure how you thought about it.
Neither am i.
> > > > Either way, we will need a document to remind us of all about
> > > > these specific symlinks and 'svn co'. I started something at
> > > > f.a.o/zone.html
> > >
> > > I have not checked it in yet because we should decide first whether we
> > > want to have /etc/apache2/ in our svn or only /etc/apache2/httpd.conf.
> > >
> > > I added it for now directly to /etc/apache2/httpd.conf and started the
> > > server (which had been down).
> >
> > Glad that more people can now start the services.
> > We need to listen to infra@ and realise it is down.
>
> Actually I submitted a patch to infrastructure to monitor lenya.zones
> with http://monitoring.apache.org/status/
>
> http://issues.apache.org/jira/browse/INFRA-698
>
> If we want, I can do the same for forrest, then we know when it is down
> and can react.
Our http server should only be down if the whole
zones machine has been rebooted. So IMO no need
for monitoring.
> > Next step is to automate the startup. See the fixme
> > note at http://forrest.apache.org/zone.html#admin
>
> Yeah on lenya we seem to have it because you cannot stop the httpd
> without another one get up instantly. I will try to find the difference
> between both configs.
We don't have any config. As you can see we must start by
hand after a reboot.
-David
Re: [zone] httpd configuration (was character entities)
Posted by Thorsten Scherler <th...@apache.org>.
El sáb, 28-01-2006 a las 17:04 +1100, David Crossley escribió:
> Thorsten Scherler wrote:
> > David Crossley escribi??:
> > > Thorsten Scherler wrote:
> > > > David Crossley escribi??:
> > ...
> > > > > At some stage we also need that httpd.conf to be in
> > > > > our forrest/zones SVN.
> > > >
> > > > Will add our http.conf into the zone svn and symlink to it.
> > >
> > > Perhaps better to have direct svn checkout, but not sure if that
> > > is possible for this httpd config.
> >
> > Hmm, actually it would but only sudos could update then.
>
> That is how it should be.
>
> > ...and do we really want all the following files in svn (seeing by the
> > public)?
> > # ls -al /etc/apache2/
> > total 340
> > drwxr-xr-x 2 root bin 512 Dec 15 01:07 .
> > drwxr-xr-x 65 root sys 3584 Jan 26 05:26 ..
> > -rw-r--r-- 1 root bin 1987 May 16 2005
> > highperformance-std.conf
> > -rw-r--r-- 1 root bin 1987 May 16 2005
> > highperformance.conf
> > -rw-r--r-- 1 root bin 37519 May 16 2005 httpd-std.conf
> > -rw-r--r-- 1 root root 37689 Jan 26 22:31 httpd.conf
> > -rw-r--r-- 1 root bin 37661 Jul 20 2005 httpd.conf-example
> > -rw-r--r-- 1 root bin 12959 May 16 2005 magic
> > -rw-r--r-- 1 root bin 15020 May 16 2005 mime.types
> > -rw-r--r-- 1 root bin 10759 May 16 2005 ssl-std.conf
> > -rw-r--r-- 1 root bin 10996 May 16 2005 ssl.conf
>
> No need to have them all in SVN, just the one that
> we want to change.
>
> I see that Cocoon put all their config into the
> pmc/cocoon section of the private committers svn.
>
Hmm, and how are they doing the checkout? I thought the private stuff is
with password and we cannot checkout stuff with a user on zones.
> We should do the same for sensitive files like httpd.conf
>
> The main stuff would stay in our forrest/zones svn,
> because that is not sensitive and is of use to
> other people.
Agree but I am not sure how you thought about it.
>
> > > Either way, we will need a document to remind us of all about
> > > these specific symlinks and 'svn co'. I started something at
> > > f.a.o/zone.html
> >
> > I have not checked it in yet because we should decide first whether we
> > want to have /etc/apache2/ in our svn or only /etc/apache2/httpd.conf.
> >
> > I added it for now directly to /etc/apache2/httpd.conf and started the
> > server (which had been down).
>
> Glad that more people can now start the services.
> We need to listen to infra@ and realise it is down.
>
Actually I submitted a patch to infrastructure to monitor lenya.zones
with http://monitoring.apache.org/status/
http://issues.apache.org/jira/browse/INFRA-698
If we want, I can do the same for forrest, then we know when it is down
and can react.
> Next step is to automate the startup. See the fixme
> note at http://forrest.apache.org/zone.html#admin
Yeah on lenya we seem to have it because you cannot stop the httpd
without another one get up instantly. I will try to find the difference
between both configs.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [zone] httpd configuration (was character entities)
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> David Crossley escribi??:
> > Thorsten Scherler wrote:
> > > David Crossley escribi??:
> ...
> > > > At some stage we also need that httpd.conf to be in
> > > > our forrest/zones SVN.
> > >
> > > Will add our http.conf into the zone svn and symlink to it.
> >
> > Perhaps better to have direct svn checkout, but not sure if that
> > is possible for this httpd config.
>
> Hmm, actually it would but only sudos could update then.
That is how it should be.
> ...and do we really want all the following files in svn (seeing by the
> public)?
> # ls -al /etc/apache2/
> total 340
> drwxr-xr-x 2 root bin 512 Dec 15 01:07 .
> drwxr-xr-x 65 root sys 3584 Jan 26 05:26 ..
> -rw-r--r-- 1 root bin 1987 May 16 2005
> highperformance-std.conf
> -rw-r--r-- 1 root bin 1987 May 16 2005
> highperformance.conf
> -rw-r--r-- 1 root bin 37519 May 16 2005 httpd-std.conf
> -rw-r--r-- 1 root root 37689 Jan 26 22:31 httpd.conf
> -rw-r--r-- 1 root bin 37661 Jul 20 2005 httpd.conf-example
> -rw-r--r-- 1 root bin 12959 May 16 2005 magic
> -rw-r--r-- 1 root bin 15020 May 16 2005 mime.types
> -rw-r--r-- 1 root bin 10759 May 16 2005 ssl-std.conf
> -rw-r--r-- 1 root bin 10996 May 16 2005 ssl.conf
No need to have them all in SVN, just the one that
we want to change.
I see that Cocoon put all their config into the
pmc/cocoon section of the private committers svn.
We should do the same for sensitive files like httpd.conf
The main stuff would stay in our forrest/zones svn,
because that is not sensitive and is of use to
other people.
> > Either way, we will need a document to remind us of all about
> > these specific symlinks and 'svn co'. I started something at
> > f.a.o/zone.html
>
> I have not checked it in yet because we should decide first whether we
> want to have /etc/apache2/ in our svn or only /etc/apache2/httpd.conf.
>
> I added it for now directly to /etc/apache2/httpd.conf and started the
> server (which had been down).
Glad that more people can now start the services.
We need to listen to infra@ and realise it is down.
Next step is to automate the startup. See the fixme
note at http://forrest.apache.org/zone.html#admin
-David
Re: [zone] httpd configuration (was character entities)
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 26-01-2006 a las 12:17 +1100, David Crossley escribió:
> Thorsten Scherler wrote:
> > David Crossley escribi??:
...
> > > At some stage we also need that httpd.conf to be in
> > > our forrest/zones SVN.
> >
> > Will add our http.conf into the zone svn and symlink to it.
>
> Perhaps better to have direct svn checkout, but not sure if that
> is possible for this httpd config.
Hmm, actually it would but only sudos could update then.
...and do we really want all the following files in svn (seeing by the
public)?
# ls -al /etc/apache2/
total 340
drwxr-xr-x 2 root bin 512 Dec 15 01:07 .
drwxr-xr-x 65 root sys 3584 Jan 26 05:26 ..
-rw-r--r-- 1 root bin 1987 May 16 2005
highperformance-std.conf
-rw-r--r-- 1 root bin 1987 May 16 2005
highperformance.conf
-rw-r--r-- 1 root bin 37519 May 16 2005 httpd-std.conf
-rw-r--r-- 1 root root 37689 Jan 26 22:31 httpd.conf
-rw-r--r-- 1 root bin 37661 Jul 20 2005 httpd.conf-example
-rw-r--r-- 1 root bin 12959 May 16 2005 magic
-rw-r--r-- 1 root bin 15020 May 16 2005 mime.types
-rw-r--r-- 1 root bin 10759 May 16 2005 ssl-std.conf
-rw-r--r-- 1 root bin 10996 May 16 2005 ssl.conf
>
> Either way, we will need a document to remind us of all about
> these specific symlinks and 'svn co'. I started something at
> f.a.o/zone.html
I have not checked it in yet because we should decide first whether we
want to have /etc/apache2/ in our svn or only /etc/apache2/httpd.conf.
I added it for now directly to /etc/apache2/httpd.conf and started the
server (which had been down).
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [zone] httpd configuration (was character entities)
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> David Crossley escribi??:
> > Thorsten Scherler wrote:
> > >
> > > Should I apply it as well for our zone? I did it only for Lenya atm and
> > > it works fine. :)
> >
> > Yes please.
> >
> > At some stage we also need that httpd.conf to be in
> > our forrest/zones SVN.
>
> Will add our http.conf into the zone svn and symlink to it.
Perhaps better to have direct svn checkout, but not sure if that
is possible for this httpd config.
Either way, we will need a document to remind us of all about
these specific symlinks and 'svn co'. I started something at
f.a.o/zone.html
> Further I
> will apply above described patch as soon I can login. Right now I get:
> ssh: connect to host forrest.zones.apache.org port 22: Connection timed
> out
Yes, the machine "helios" is down:
http://www.apache.org/dev/#status
-David
Re: [zone] httpd configuration (was character entities)
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 26-01-2006 a las 09:19 +1100, David Crossley escribió:
> Thorsten Scherler wrote:
> >
> > sudo su
> > vi /etc/apache2/httpd.conf
> > find "Directory" and add the "" the part should look like:
> >
> > # First, we configure the "default" to be a very restrictive set of
> > # features.
> > #
> > <Directory />
> > Options FollowSymLinks
> > AllowOverride None
> > AddDefaultCharset UTF-8
> > </Directory>
> >
> > That is better as stated in
> > http://httpd.apache.org/docs/2.2/howto/htaccess.html since
> > "However, in general, use of .htaccess files should be avoided when
> > possible. Any configuration that you would consider putting in
> > a .htaccess file, can just as effectively be made in a <Directory>
> > section in your main server configuration file."
> >
> > Should I apply it as well for our zone? I did it only for Lenya atm and
> > it works fine. :)
>
> Yes please.
>
> At some stage we also need that httpd.conf to be in
> our forrest/zones SVN.
>
Will add our http.conf into the zone svn and symlink to it. Further I
will apply above described patch as soon I can login. Right now I get:
ssh: connect to host forrest.zones.apache.org port 22: Connection timed
out
salu2
> -David
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [zone] httpd configuration (was character entities)
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
>
> sudo su
> vi /etc/apache2/httpd.conf
> find "Directory" and add the "" the part should look like:
>
> # First, we configure the "default" to be a very restrictive set of
> # features.
> #
> <Directory />
> Options FollowSymLinks
> AllowOverride None
> AddDefaultCharset UTF-8
> </Directory>
>
> That is better as stated in
> http://httpd.apache.org/docs/2.2/howto/htaccess.html since
> "However, in general, use of .htaccess files should be avoided when
> possible. Any configuration that you would consider putting in
> a .htaccess file, can just as effectively be made in a <Directory>
> section in your main server configuration file."
>
> Should I apply it as well for our zone? I did it only for Lenya atm and
> it works fine. :)
Yes please.
At some stage we also need that httpd.conf to be in
our forrest/zones SVN.
-David
Re: [zone] httpd configuration (was character entities)
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 24-01-2006 a las 23:43 +0100, Thorsten Scherler escribió:
> El mié, 25-01-2006 a las 09:23 +1100, David Crossley escribió:
> > Thorsten Scherler wrote:
> > > David Crossley escribi??:
> > > >
> > > > On forrest.apache.org we have this workaround in our .htaccess
> > > > AddDefaultCharset UTF-8
> > > >
> > > > However we don't yet have that on forrest.zones.apache.org as
> > > > our httpd instance needs other configuration too.
> > >
> > > Yeah, I tried the .htaccess tip but like you stated there are some other
> > > configurations to do.
> > >
> > > Do you know which or maybe can point me to some resources?
> >
> > http://httpd.apache.org/docs/2.2/
> >
> > Need to enable the use of .htaccess files.
> >
>
> Thx, will have a look.
>
sudo su
vi /etc/apache2/httpd.conf
find "Directory" and add the "" the part should look like:
# First, we configure the "default" to be a very restrictive set of
# features.
#
<Directory />
Options FollowSymLinks
AllowOverride None
AddDefaultCharset UTF-8
</Directory>
That is better as stated in
http://httpd.apache.org/docs/2.2/howto/htaccess.html since
"However, in general, use of .htaccess files should be avoided when
possible. Any configuration that you would consider putting in
a .htaccess file, can just as effectively be made in a <Directory>
section in your main server configuration file."
Should I apply it as well for our zone? I did it only for Lenya atm and
it works fine. :)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [zone] httpd configuration (was character entities)
Posted by Thorsten Scherler <th...@apache.org>.
El mié, 25-01-2006 a las 09:23 +1100, David Crossley escribió:
> Thorsten Scherler wrote:
> > David Crossley escribi??:
> > >
> > > On forrest.apache.org we have this workaround in our .htaccess
> > > AddDefaultCharset UTF-8
> > >
> > > However we don't yet have that on forrest.zones.apache.org as
> > > our httpd instance needs other configuration too.
> >
> > Yeah, I tried the .htaccess tip but like you stated there are some other
> > configurations to do.
> >
> > Do you know which or maybe can point me to some resources?
>
> http://httpd.apache.org/docs/2.2/
>
> Need to enable the use of .htaccess files.
>
Thx, will have a look.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [zone] httpd configuration (was character entities)
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> David Crossley escribi??:
> >
> > On forrest.apache.org we have this workaround in our .htaccess
> > AddDefaultCharset UTF-8
> >
> > However we don't yet have that on forrest.zones.apache.org as
> > our httpd instance needs other configuration too.
>
> Yeah, I tried the .htaccess tip but like you stated there are some other
> configurations to do.
>
> Do you know which or maybe can point me to some resources?
http://httpd.apache.org/docs/2.2/
Need to enable the use of .htaccess files.
-David
[zone] httpd configuration (was character entities)
Posted by Thorsten Scherler <th...@apache.org>.
El lun, 23-01-2006 a las 11:43 +1100, David Crossley escribió:
> Thorsten Scherler wrote:
> >
> > Yeah, I am running into the same problem ATM. You can see it online at
> > http://lenya.zones.apache.org/ "Today:??..." (I am looking right now to
> > fix that, so the site may be fixed if you visit it)
> >
> > On my local machine that does not happen. I have run into a similar
> > problem with cocoon on a job I did a while ago. The problem was lying in
> > the server configuration, now I just looked on our zones server:
> > Sun Microsystems Inc. SunOS 5.10 Generic January 2005
> > -bash-3.00$ locale
> > LANG=
> > LC_CTYPE="C"
> > LC_NUMERIC="C"
> > LC_TIME="C"
> > LC_COLLATE="C"
> > LC_MONETARY="C"
> > LC_MESSAGES="C"
> > LC_ALL=
> >
> > The locale is not UTF-8!
> >
> > Doing "locale" on my machine gives:
> > LANG=es_ES.UTF-8
> > LC_CTYPE="es_ES.UTF-8"
> > LC_NUMERIC="es_ES.UTF-8"
> > LC_TIME="es_ES.UTF-8"
> > LC_COLLATE="es_ES.UTF-8"
> > LC_MONETARY="es_ES.UTF-8"
> > LC_MESSAGES="es_ES.UTF-8"
> > LC_PAPER="es_ES.UTF-8"
> > LC_NAME="es_ES.UTF-8"
> > LC_ADDRESS="es_ES.UTF-8"
> > LC_TELEPHONE="es_ES.UTF-8"
> > LC_MEASUREMENT="es_ES.UTF-8"
> > LC_IDENTIFICATION="es_ES.UTF-8"
> > LC_ALL=
> >
> > That is UTF-8!
> >
> > The solution back on the job was setting the language to de_DE.UTF-8
> > before starting the tomcat server.
> >
I tried this but the httpd on zone is started differently like on other
unix systems. I am still looking for a way how to "teach apache2" to use
utf-8 locales.
Finding
http://marc.theaimsgroup.com/?t=113761190300004&r=1&w=2
makes it clear that even if you set the env to utf-8 prior to the start
of httpd it will get ignored. :(
> > >
...
> >
> > Actually regarding http://www.html-world.de/program/html_sz.php
> > Unicode:
> > XML:  
> > Result: space
> >
> > We are using the right code for spaces. I guess you need to set the
> > locale to UTF-8 on the server (before starting httpd), since forrest is
> > rendering it on lenya.zones just fine but the httpd is delivering the
> > content with "??".
>
> On forrest.apache.org we have this workaround in our .htaccess
> AddDefaultCharset UTF-8
>
> However we don't yet have that on forrest.zones.apache.org as
> our httpd instance needs other configuration too.
Yeah, I tried the .htaccess tip but like you stated there are some other
configurations to do.
Do you know which or maybe can point me to some resources?
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: character entities
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
>
> Yeah, I am running into the same problem ATM. You can see it online at
> http://lenya.zones.apache.org/ "Today:??..." (I am looking right now to
> fix that, so the site may be fixed if you visit it)
>
> On my local machine that does not happen. I have run into a similar
> problem with cocoon on a job I did a while ago. The problem was lying in
> the server configuration, now I just looked on our zones server:
> Sun Microsystems Inc. SunOS 5.10 Generic January 2005
> -bash-3.00$ locale
> LANG=
> LC_CTYPE="C"
> LC_NUMERIC="C"
> LC_TIME="C"
> LC_COLLATE="C"
> LC_MONETARY="C"
> LC_MESSAGES="C"
> LC_ALL=
>
> The locale is not UTF-8!
>
> Doing "locale" on my machine gives:
> LANG=es_ES.UTF-8
> LC_CTYPE="es_ES.UTF-8"
> LC_NUMERIC="es_ES.UTF-8"
> LC_TIME="es_ES.UTF-8"
> LC_COLLATE="es_ES.UTF-8"
> LC_MONETARY="es_ES.UTF-8"
> LC_MESSAGES="es_ES.UTF-8"
> LC_PAPER="es_ES.UTF-8"
> LC_NAME="es_ES.UTF-8"
> LC_ADDRESS="es_ES.UTF-8"
> LC_TELEPHONE="es_ES.UTF-8"
> LC_MEASUREMENT="es_ES.UTF-8"
> LC_IDENTIFICATION="es_ES.UTF-8"
> LC_ALL=
>
> That is UTF-8!
>
> The solution back on the job was setting the language to de_DE.UTF-8
> before starting the tomcat server.
>
> > I am seeing ?? a lot lately and so think the problem is still not solved.
>
> Yeah, we need to find the root cause of this problem. I guess it is
> lying in the "locale".
>
> > For instance it is the result of siteinfo-last-published.ft.
> >
> > Last Published:?? 01/21/2006 17:53:37
> >
> > This line is created from the contract here :-
> >
> > <xsl:template name="siteinfo-last-published-body">
> > <script type="text/javascript">document.write("<i18n:text >Last
> > Published:</i18n:text> " + document.lastModified);</script>
> > </xsl:template>
> >
> > I have a theory.
> >
> > in the code the   is right next to a " (quote). The entity number for "
> > (quote) is "
> >
> > I had a crazy thought that maybe they were adding together somehow.
> > (160+34=194)
> >
> >   + " = Â
> >
> > Guess what  is equal to , yup :-
> >
> > ??
>
> Jeje, nice theory, but I have an example where you do not combine  
> with " and still the described behavior can be seen.
>
> <forrest:hook class="breadtrail">
> <forrest:contract name="genericMarkup">
> <forrest:properties contract="genericMarkup">
> <forrest:property name="genericMarkup">
> <strong> </strong>
> </forrest:property>
> </forrest:properties>
> </forrest:contract>
> </forrest:hook>
>
>
> >
> > Anyway, in the example contract code above, removing   and putting a
> > real space in there cures it and the space
> > is preserved no problem as it is enclosed between the quotes.
> >
> > I copied the contract to my /pili/html/ directory and it now renders
> > correctly.
> >
> > Have I missed something here or was it that simple ?
> >
>
> Actually regarding http://www.html-world.de/program/html_sz.php
> Unicode:
> XML:  
> Result: space
>
> We are using the right code for spaces. I guess you need to set the
> locale to UTF-8 on the server (before starting httpd), since forrest is
> rendering it on lenya.zones just fine but the httpd is delivering the
> content with "??".
On forrest.apache.org we have this workaround in our .htaccess
AddDefaultCharset UTF-8
However we don't yet have that on forrest.zones.apache.org as
our httpd instance needs other configuration too.
-David
> More information about utf-8 and unicode can be found on [1]. How to set
> it in Gentoo [2] is in spanish only but I reckon you still can get the
> idea following the coding examples. Finally [3] a smaller howto in
> english.
>
> HTH
> salu2
>
> [1]http://www.cl.cam.ac.uk/~mgk25/unicode.html
> [2]http://es.gentoo-wiki.com/Unicode-UTF-8
> [3]http://www.linux.com/howtos/Indic-Fonts-HOWTO/locale.shtml
> --
> thorsten
>
> "Together we stand, divided we fall!"
> Hey you (Pink Floyd)
>
Re: Example use case - working example
Posted by Ross Gardler <rg...@apache.org>.
Gav.... wrote:
> Ok, so I now have something to work with.
>
> So you know, this is a summary of what I did. (There is a question at the
> end of all this)
>
> 1. Followed Davids Dispatcher Quick Start with a 'forrest test-sample'
> rather than seed-v2.
> 2. Copied Ross' coat.fv into
> /project_home/src/documentation/resources/themes/pili.fv
> 3. In /themes/ dir created /pili/ subdir and in /pili/ created /css/ subdir.
> 4. Copied Ross' coat.css into /themes/pili/css/ directory.
> 5. Edit forrest.properties and changed 'project.theme=pelt' to
> 'project.theme=pili'
> 6. 'forrest run' from project_home, works fine, Ross' default theme shows up
> nicely.
> 7. Made a few changes to pili.fv, refresh browser shows them nicely.
> 8. Made changes to pili.css, however file is locked for use and can not save
> changes.
I've noticed this happening on windows too. It doesn't always happen. I
find that if you refresh the browser again it will usually release the lock.
I've never noticed this happen on Linux.
> 9. Stop Jetty, Make changes to pili.css, restart with 'forrest run' , css
> changes show up fine.
See above.
> 10. Complete rework of CSS adding more of my own stuff, rework pili.fv also.
> (hence the renaming of ross' coat into pili, didnt want to spoil it.)
> 11. Upload to web space using ForrestBot.
> 12. Test in Web Browser, looks the same as localhost:8888 as it should.
Cool ;-)
Can you put the above into a "how to create a new theme" faq. Remove all
references to "Ross'" - it's not mine its the communities, it even has
code from your good self in it remember ;-)
Don't worry that the above is just a load of bullet points, a start for
documentation is always useful.
> The above should see most people through, after more testing I want to make
> it known :-
>
> 13. Make some more changes to pili.fv and pili.css.
> 14. Tested local, works fine.
> 15. Uploaded to webspace using ForrestBot.
> 16. Changes do not seem to have made it onto server.
>
> Some changes I made required that an index.fv be deleted. ForrestBot does
> not know how to
> delete from server, hence my changes were not carried across.
Please raise an issue for this one, we'll need to sort that out.
> Anyway, as a recap, I wanted my pili theme to more or less resemble
> http://minitutorials.com
>
> Here is my first attempt at getting it like that, it is not yet complete -
> http://apache.minitutorials.com
>
> I hope you agree they are similar.
Yep, you are certainly moving forward :-)
> Now for the question, in fact, no I'll put it in a different subject.
OK...
Ross
Re: Example use case - working example
Posted by "Gav...." <br...@brightontown.com.au>.
Ok, so I now have something to work with.
So you know, this is a summary of what I did. (There is a question at the
end of all this)
1. Followed Davids Dispatcher Quick Start with a 'forrest test-sample'
rather than seed-v2.
2. Copied Ross' coat.fv into
/project_home/src/documentation/resources/themes/pili.fv
3. In /themes/ dir created /pili/ subdir and in /pili/ created /css/ subdir.
4. Copied Ross' coat.css into /themes/pili/css/ directory.
5. Edit forrest.properties and changed 'project.theme=pelt' to
'project.theme=pili'
6. 'forrest run' from project_home, works fine, Ross' default theme shows up
nicely.
7. Made a few changes to pili.fv, refresh browser shows them nicely.
8. Made changes to pili.css, however file is locked for use and can not save
changes.
9. Stop Jetty, Make changes to pili.css, restart with 'forrest run' , css
changes show up fine.
10. Complete rework of CSS adding more of my own stuff, rework pili.fv also.
(hence the renaming of ross' coat into pili, didnt want to spoil it.)
11. Upload to web space using ForrestBot.
12. Test in Web Browser, looks the same as localhost:8888 as it should.
The above should see most people through, after more testing I want to make
it known :-
13. Make some more changes to pili.fv and pili.css.
14. Tested local, works fine.
15. Uploaded to webspace using ForrestBot.
16. Changes do not seem to have made it onto server.
Some changes I made required that an index.fv be deleted. ForrestBot does
not know how to
delete from server, hence my changes were not carried across.
Anyway, as a recap, I wanted my pili theme to more or less resemble
http://minitutorials.com
Here is my first attempt at getting it like that, it is not yet complete -
http://apache.minitutorials.com
I hope you agree they are similar.
Now for the question, in fact, no I'll put it in a different subject.
Gav...
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date: 20/01/2006
Re: Best way to add repeatable code in v2/v3 (was Re: Example
usecase)
Posted by Thorsten Scherler <th...@apache.org>.
El lun, 30-01-2006 a las 16:06 +0800, Gav.... escribió:
...
>
> As soon as you change it on a regular basis and
> | would need to have different code on different pages it makes sense to
> |
> | 2) create a custom business service
> | A custom business service is an extension of forrest core data models.
> | In the dataModel.xmap you can find the core models. You can add your own
> | service to your project sitemap. Like:
> | <map:match pattern="includes.rightbar.**.xml">
> | <map:generate src="{project:resources}/includes/rightbar/{1}.xml" />
> | <map:serialize type="xml"/>
> | </map:match>
> |
> | This assumes that you move to xml instead of html output (remember you
> | can use html like grammar in xml).
> |
> | Now you could define the contract like:
> | <forrest:contract name="content-include-rightbar">
> | <forrest:properties contract="content-include-rightbar">
> | <forrest:property name="content-include-rightbar"
> | nugget="get.nugget.include.rightbar">
> | <jx:import
> | uri="cocoon://includes.rightbar.#{$cocoon/parameters/getRequest}.xml"/>
> | </forrest:property>
> | </forrest:properties>
> | </forrest:contract>
> |
> | and the contract:
> | <xsl:template name="content-include-rightbar-body" >
> | <xsl:param name="content-include-rightbar"/>
> | <xsl:copy-of
> | select="$content-include-rightbar/*"/>
> | </xsl:template>
>
> I have been looking at this only in them email and not tried yet
> to implement it. I just can not see at the moment how to use this
> to apply slightly varying content to different pages.
>
> For instance, look at the right hand side of
> http://www.minitutorials.com/apache/apacheindex.shtml.
>
> There is a 'This page sponsored by' div and then below it is another
> div with the sponsor image and info. This div is the only div that will be
> different on all pages. Everything else on the right hand side will be
> exactly the same for the whole site.
So then you have to split the stuff that changes apart from the static
content.
>
> So this custom business service 'sounds' like what I need, just I can't
> see how to implement it.
Ok, to find out:
Do your sponsored pages follow some rule? I mean on page xy there is
always sponsor z, or a similar rule. Or are this sponsor link
dynamically and will change even after a refresh of the site?
>
> Does anyone have any ideas on the how ?
Actually it is all a little bit further on the top.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Best way to add repeatable code in v2/v3 (was Re: Example usecase)
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Thorsten Scherler" <th...@apache.org>
To: <de...@forrest.apache.org>
Sent: Monday, January 23, 2006 1:19 AM
Subject: Re: Best way to add repeatable code in v2/v3 (was Re: Example
usecase)
<snip>
|
| <forrest:contract name="content-include-html">
| <forrest:properties contract="content-include-html">
| <forrest:property name="content-include-html"
| nugget="get.nugget.include.html">
| <jx:import uri="cocoon://includes.rightbar.html"/>
| </forrest:property>
| </forrest:properties>
| </forrest:contract>
|
| ...but be aware that this contract expect a <div id="content"/>:
| <xsl:copy-of select="$content-include-html//div[@id='content']/*"/>
As I said in another mail, I could not get this to work, but doesn't
matter now anyway, thought I'd mention it in case the problem
was was also a sympton for something else.
|
| > Alternative I thought of would be to create a contract for it. Although
I
| > can see how to
| > create a contract, not sure again on the best way of approaching it.
Maybe
| > doing a similar
| > thing as including the body from say index.xml but using
| > rightnavcontent.xml, use jx: ??
| >
|
| Actually I think in your case it would makes sense to create a contract.
|
| Now you have different options to implement it.
|
| 1) controlled by the structurer
| You can use the genericMarkup.ft
| <forrest:contract name="genericMarkup">
| <forrest:properties contract="genericMarkup">
| <forrest:property name="genericMarkup">
| <div class="rightsub">
| <h5>Sponsor This Site!</h5>
| </div>
| </forrest:property>
| </forrest:properties>
| </forrest:contract>
|
| You would do this if the code is added to all pages and actually does
| not change too much.
I have done this and works fine, http://apache.minitutorials.com/ is
updated.
As soon as you change it on a regular basis and
| would need to have different code on different pages it makes sense to
|
| 2) create a custom business service
| A custom business service is an extension of forrest core data models.
| In the dataModel.xmap you can find the core models. You can add your own
| service to your project sitemap. Like:
| <map:match pattern="includes.rightbar.**.xml">
| <map:generate src="{project:resources}/includes/rightbar/{1}.xml" />
| <map:serialize type="xml"/>
| </map:match>
|
| This assumes that you move to xml instead of html output (remember you
| can use html like grammar in xml).
|
| Now you could define the contract like:
| <forrest:contract name="content-include-rightbar">
| <forrest:properties contract="content-include-rightbar">
| <forrest:property name="content-include-rightbar"
| nugget="get.nugget.include.rightbar">
| <jx:import
| uri="cocoon://includes.rightbar.#{$cocoon/parameters/getRequest}.xml"/>
| </forrest:property>
| </forrest:properties>
| </forrest:contract>
|
| and the contract:
| <xsl:template name="content-include-rightbar-body" >
| <xsl:param name="content-include-rightbar"/>
| <xsl:copy-of
| select="$content-include-rightbar/*"/>
| </xsl:template>
I have been looking at this only in them email and not tried yet
to implement it. I just can not see at the moment how to use this
to apply slightly varying content to different pages.
For instance, look at the right hand side of
http://www.minitutorials.com/apache/apacheindex.shtml.
There is a 'This page sponsored by' div and then below it is another
div with the sponsor image and info. This div is the only div that will be
different on all pages. Everything else on the right hand side will be
exactly the same for the whole site.
So this custom business service 'sounds' like what I need, just I can't
see how to implement it.
Does anyone have any ideas on the how ?
Thorsten, I know you have a real work-load on, so just say 'too busy'
if you like and I'll look a bit deeper into it myself.
Thanks
Gav...
| HTH
| salu2
| --
| thorsten
|
| "Together we stand, divided we fall!"
| Hey you (Pink Floyd)
|
|
|
|
| --
| No virus found in this incoming message.
| Checked by AVG Free Edition.
| Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date:
20/01/2006
|
|
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.23/243 - Release Date: 27/01/2006
Re: Best way to add repeatable code in v2/v3 (was Re: Example usecase)
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Thorsten Scherler" <th...@apache.org>
To: <de...@forrest.apache.org>
Sent: Monday, January 23, 2006 1:19 AM
Subject: Re: Best way to add repeatable code in v2/v3 (was Re: Example
usecase)
<snip>
| >
| > 2. Then I looked through ls.contracts and found one I thought might be
| > suitable as replacement of 'include/require'
| > Adding the code for it into my hooks above I ended up with :-
| >
| > <forrest:hook name="headlines">
| > <forrest:hook name="rightbar">
| > <forrest:contract name="search-input">
| > <forrest:properties contract="search-input">
| > <forrest:property name="search-input">
| > <search name="minitutorials"
domain="www.minitutorials.com"
| > provider="google"/>
| > </forrest:property>
| > </forrest:properties>
| > </forrest:contract>
| > <forrest:contract name="content-include-html">
| > <forrest:properties contract="content-include-html">
| > <forrest:property name="content-include-html"
| > nugget="get.nugget.include.html">
| > <url>/rightbar.html</url>
| > </forrest:property>
| > </forrest:properties>
| > </forrest:contract>
| > </forrest:hook>
| > </forrest:hook>
| >
| > (content-include sounds just what I need)
|
| Hmm, not directly.
| 1) it is a v1 contract. <url>/rightbar.html</url> is not aviable
| anymore. This have to be done with jx:import.
| 2) the syntax you use expects rightbar.html *not* in the docroot but the
| the file path /rightbar.html!
|
| >
| > 3. The html code required I transfered from rightnav.ssi into
rightnav.html
| > and put this file
| > into xdocs directory. I am hoping that the <url>/rightbar.html</url> is
| > therefore correct.
|
| no, see above
|
| >
| > 4. Didn't see what else I would need to do, so did a 'forrest run' , did
not
| > show up.
| > Also did a ForrestBot onto the web server, also does not show up.
| >
| > So, this did not work, the question is, have I done something wrong,
missed
| > something out
| > or is there a different/better way to include content into the
'headlines'
| > hook ?
| >
|
| <forrest:contract name="content-include-html">
| <forrest:properties contract="content-include-html">
| <forrest:property name="content-include-html"
| nugget="get.nugget.include.html">
| <jx:import uri="cocoon://includes.rightbar.html"/>
| </forrest:property>
| </forrest:properties>
| </forrest:contract>
|
| ...but be aware that this contract expect a <div id="content"/>:
| <xsl:copy-of select="$content-include-html//div[@id='content']/*"/>
Ouch!, It didn't like like one bit. I added the above contract into pili.fv.
I then wrapped the entire rightbar.html code into the required <div
id="content"> ...</div>
(After testing I was going to alter the contract so I wouldnt need to do
this)
Forrest Run
http://localhost:8888
(wait 10 minutes, computer slows to a crawl.)
Page can not be displayed ..
errors from jetty, inlcude:
popContextNodeList when stack is empty!
Logging Error: Unknown error writing event.
java.lang.OutOfMemoryError: Java Heap Space.
Above 3 lines repeated forever.
I then remove content-include-html contract from pili.fv
Refresh browser, all works fine again.
Will try again. Just to confirm 'rightbar.html' is in /xdocs/
|
| > Alternative I thought of would be to create a contract for it. Although
I
| > can see how to
| > create a contract, not sure again on the best way of approaching it.
Maybe
| > doing a similar
| > thing as including the body from say index.xml but using
| > rightnavcontent.xml, use jx: ??
| >
|
| Actually I think in your case it would makes sense to create a contract.
|
| Now you have different options to implement it.
|
| 1) controlled by the structurer
| You can use the genericMarkup.ft
| <forrest:contract name="genericMarkup">
| <forrest:properties contract="genericMarkup">
| <forrest:property name="genericMarkup">
| <div class="rightsub">
| <h5>Sponsor This Site!</h5>
| </div>
| </forrest:property>
| </forrest:properties>
| </forrest:contract>
|
| You would do this if the code is added to all pages and actually does
| not change too much.
90% of the code would be on all pages. It is mainly a site news type of
area and so would change infrequently, maybe once a month or two months.
The other '10%' is geared to a sponsor ad, one sponsor per page and an
overall site sponsor, so this part would be different on all pages.
|As soon as you change it on a regular basis and
| would need to have different code on different pages it makes sense to
|
| 2) create a custom business service
| A custom business service is an extension of forrest core data models.
| In the dataModel.xmap you can find the core models. You can add your own
| service to your project sitemap. Like:
| <map:match pattern="includes.rightbar.**.xml">
| <map:generate src="{project:resources}/includes/rightbar/{1}.xml" />
| <map:serialize type="xml"/>
| </map:match>
|
| This assumes that you move to xml instead of html output (remember you
| can use html like grammar in xml).
|
| Now you could define the contract like:
| <forrest:contract name="content-include-rightbar">
| <forrest:properties contract="content-include-rightbar">
| <forrest:property name="content-include-rightbar"
| nugget="get.nugget.include.rightbar">
| <jx:import
| uri="cocoon://includes.rightbar.#{$cocoon/parameters/getRequest}.xml"/>
| </forrest:property>
| </forrest:properties>
| </forrest:contract>
|
| and the contract:
| <xsl:template name="content-include-rightbar-body" >
| <xsl:param name="content-include-rightbar"/>
| <xsl:copy-of
| select="$content-include-rightbar/*"/>
| </xsl:template>
Ok, this sounds to be the best way to go, but I can not see how to implement
it as
the 10% is different on all pages. (I created different inlcudes currently)
| 3) ...
|
| I can actually think on a couple of other ways how to include extra stuff
but it always depend on the usecase.
| Questions like:
| - is the content request aware?
Not at the moment, in the future I'll probably add back in a bit of PHP, but
not yet
I'll get it working without first.
| - does it makes sense to create a custom business service?
Not sure. It seems to me Im stuck between this and the genericMarkup.ft. ??
| - will the content included and actually never changed?
It will change infrequently.
| - do you need a contract that you can reuse in different projects?
No
| - how generic the contract has to be?
90% :-)
Gav...
| ....
|
| HTH
| salu2
| --
| thorsten
|
| "Together we stand, divided we fall!"
| Hey you (Pink Floyd)
|
|
|
|
| --
| No virus found in this incoming message.
| Checked by AVG Free Edition.
| Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date:
20/01/2006
|
|
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.23/240 - Release Date: 25/01/2006
Re: Best way to add repeatable code in v2/v3 (was Re: Example use
case)
Posted by Thorsten Scherler <th...@apache.org>.
El sáb, 21-01-2006 a las 20:06 +0800, Gav.... escribió:
> Hi All,
>
> On the right hand side of http://minitutorials.com I have some 'headlines'
> in a 'headlines' div
> All boxes are in a 'rightbar' div also.
> The code for this is in One file called rightnav.ssi and included using
> either 'include' or 'require'
> This obviously has the effect that all of the site pages get the content
> from the one file.
>
> I have been looking at how to do this using dispatcher method.
>
> What I have tried :-
>
> 1. Create Hooks as required to get the div and css to position it.
>
> <forrest:hook name="headlines">
> <forrest:hook name="rightbar">
> <forrest:contract name="search-input">
> <forrest:properties contract="search-input">
> <forrest:property name="search-input">
> <search name="minitutorials" domain="www.minitutorials.com"
> provider="google"/>
> </forrest:property>
> </forrest:properties>
> </forrest:contract>
> </forrest:hook>
> </forrest:hook>
>
> As you can see I have added a search-input so the div shows on the site and
> is present at http://apache.minitutorials.com
yeah, nice.
>
> 2. Then I looked through ls.contracts and found one I thought might be
> suitable as replacement of 'include/require'
> Adding the code for it into my hooks above I ended up with :-
>
> <forrest:hook name="headlines">
> <forrest:hook name="rightbar">
> <forrest:contract name="search-input">
> <forrest:properties contract="search-input">
> <forrest:property name="search-input">
> <search name="minitutorials" domain="www.minitutorials.com"
> provider="google"/>
> </forrest:property>
> </forrest:properties>
> </forrest:contract>
> <forrest:contract name="content-include-html">
> <forrest:properties contract="content-include-html">
> <forrest:property name="content-include-html"
> nugget="get.nugget.include.html">
> <url>/rightbar.html</url>
> </forrest:property>
> </forrest:properties>
> </forrest:contract>
> </forrest:hook>
> </forrest:hook>
>
> (content-include sounds just what I need)
Hmm, not directly.
1) it is a v1 contract. <url>/rightbar.html</url> is not aviable
anymore. This have to be done with jx:import.
2) the syntax you use expects rightbar.html *not* in the docroot but the
the file path /rightbar.html!
>
> 3. The html code required I transfered from rightnav.ssi into rightnav.html
> and put this file
> into xdocs directory. I am hoping that the <url>/rightbar.html</url> is
> therefore correct.
no, see above
>
> 4. Didn't see what else I would need to do, so did a 'forrest run' , did not
> show up.
> Also did a ForrestBot onto the web server, also does not show up.
>
> So, this did not work, the question is, have I done something wrong, missed
> something out
> or is there a different/better way to include content into the 'headlines'
> hook ?
>
<forrest:contract name="content-include-html">
<forrest:properties contract="content-include-html">
<forrest:property name="content-include-html"
nugget="get.nugget.include.html">
<jx:import uri="cocoon://includes.rightbar.html"/>
</forrest:property>
</forrest:properties>
</forrest:contract>
...but be aware that this contract expect a <div id="content"/>:
<xsl:copy-of select="$content-include-html//div[@id='content']/*"/>
> Alternative I thought of would be to create a contract for it. Although I
> can see how to
> create a contract, not sure again on the best way of approaching it. Maybe
> doing a similar
> thing as including the body from say index.xml but using
> rightnavcontent.xml, use jx: ??
>
Actually I think in your case it would makes sense to create a contract.
Now you have different options to implement it.
1) controlled by the structurer
You can use the genericMarkup.ft
<forrest:contract name="genericMarkup">
<forrest:properties contract="genericMarkup">
<forrest:property name="genericMarkup">
<div class="rightsub">
<h5>Sponsor This Site!</h5>
</div>
</forrest:property>
</forrest:properties>
</forrest:contract>
You would do this if the code is added to all pages and actually does
not change too much. As soon as you change it on a regular basis and
would need to have different code on different pages it makes sense to
2) create a custom business service
A custom business service is an extension of forrest core data models.
In the dataModel.xmap you can find the core models. You can add your own
service to your project sitemap. Like:
<map:match pattern="includes.rightbar.**.xml">
<map:generate src="{project:resources}/includes/rightbar/{1}.xml" />
<map:serialize type="xml"/>
</map:match>
This assumes that you move to xml instead of html output (remember you
can use html like grammar in xml).
Now you could define the contract like:
<forrest:contract name="content-include-rightbar">
<forrest:properties contract="content-include-rightbar">
<forrest:property name="content-include-rightbar"
nugget="get.nugget.include.rightbar">
<jx:import
uri="cocoon://includes.rightbar.#{$cocoon/parameters/getRequest}.xml"/>
</forrest:property>
</forrest:properties>
</forrest:contract>
and the contract:
<xsl:template name="content-include-rightbar-body" >
<xsl:param name="content-include-rightbar"/>
<xsl:copy-of
select="$content-include-rightbar/*"/>
</xsl:template>
3) ...
I can actually think on a couple of other ways how to include extra stuff but it always depend on the usecase.
Questions like:
- is the content request aware?
- does it makes sense to create a custom business service?
- will the content included and actually never changed?
- do you need a contract that you can reuse in different projects?
- how generic the contract has to be?
....
HTH
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Best way to add repeatable code in v2/v3 (was Re: Exampleusecase)
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Thorsten Scherler" <th...@apache.org>
To: <de...@forrest.apache.org>
Sent: Sunday, January 22, 2006 9:56 PM
Subject: Re: Best way to add repeatable code in v2/v3 (was Re:
Exampleusecase)
| El dom, 22-01-2006 a las 21:38 +0800, Gav.... escribió:
| > ----- Original Message -----
| > From: "Thorsten Scherler" <th...@apache.org>
| > To: <de...@forrest.apache.org>
| > Sent: Sunday, January 22, 2006 9:26 PM
| > Subject: Re: Best way to add repeatable code in v2/v3 (was Re: Example
| > usecase)
| >
| >
| > | El dom, 22-01-2006 a las 21:09 +0800, Gav.... escribió:
| > | ...
| > | > |
| > | > | > P.S-
| > | > | >
| > | > | > Creating an empty hook has the side effect of a self closing
div -
| > | > obviously
| > | > | > inlvalid and messes
| > | > | > up the rest of the page.
| > | > |
| > | > | Raise an issue (if there isn't one already, this is ringing a bell
| > | > | somewhere in the deep recesses of my mind).
| > | >
| > | > I will raise an issue, I had a good look for one but could not
| > | > find a relevent one.
| > |
| > | Hmm, did you read the other mail I wrote?
| >
| > Yes, I posted this earlier than that one arrived though.
| >
| > |
| > |
| >
forrest-trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/resources/stylesheets/hooksMatcher.xsl
| > | ...
| > | <xsl:if test="@nbsp='true'"> </xsl:if>
| > | ...
| > |
| > | Meaning
| > | <forrest:hook name="headlines"></forrest:hook>
| > | creates
| > | <div id="headlines />
| > |
| > | and <forrest:hook name="headlines" nbsp="true"></forrest:hook>
| > | gives
| > | <div id="headlines"> </div>
| > |
| > | We need to document this in the howto, but self enclosing divs are
| > | default in the dispatcher, no bug!
| >
| > Thats fine, I will send in a patch to document this. I can not really
| > think of a situation (except in testing) where I would want an
| > empty div anyway, but came across it so mentioned it.
|
| Actually since Cyriaque and yourself seem to prefer that the default
| behavior would be non enclosing divs we can change the default
| behavior.
|
| wdyt?
Personally I think it wise to do so, especially if we are aiming to
adhere to W3C XHTML2 standards, where this is a must.
There are certain elements thsat can self close, <separator /> etc
but div is not one of them.
In the hooksMatcher.xsl, would you change true to false then?
Thanks
Gav...
|
| >
| > I did see the resolution you mention in the whiteboard and on list [1]
| > but wasn't sure of the final outcome.
| >
| > Thanks. Now if you could point me in the right direction regarding
| > the subject title ;>)
|
| jeje, yeah, after I fixed the httpd bug on lenya.zones.
|
| salu2
|
| >
| > [1] -
| >
http://mail-archives.apache.org/mod_mbox/forrest-dev/200507.mbox/%3C42EA35BD.5080008@pcotech.fr%3E
| >
| > Gav...
| >
| > |
| > | salu2
| > | --
| > | thorsten
| > |
| > | "Together we stand, divided we fall!"
| > | Hey you (Pink Floyd)
| > |
| > |
| > |
| > |
| > | --
| > | No virus found in this incoming message.
| > | Checked by AVG Free Edition.
| > | Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date:
| > 20/01/2006
| > |
| > |
| >
| >
| >
| --
| thorsten
|
| "Together we stand, divided we fall!"
| Hey you (Pink Floyd)
|
|
|
|
| --
| No virus found in this incoming message.
| Checked by AVG Free Edition.
| Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date:
20/01/2006
|
|
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date: 20/01/2006
Re: Best way to add repeatable code in v2/v3 (was Re:Exampleusecase)
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Thorsten Scherler" <th...@wyona.com>
To: <de...@forrest.apache.org>
Sent: Friday, January 27, 2006 8:24 PM
Subject: Re: Best way to add repeatable code in v2/v3 (was
Re:Exampleusecase)
| El vie, 27-01-2006 a las 17:59 +0800, Gav.... escribió:
| > ----- Original Message -----
|
| ...
| > |
| > | Actually since Cyriaque and yourself seem to prefer that the default
| > | behavior would be non enclosing divs we can change the default
| > | behavior.
| > |
| > | wdyt?
| >
| > I have found another reason why it is best to close these divs properly.
| >
| > e.g.
| >
| > <forrest:contract name="content-abstract">
| > <forrest:properties contract="content-abstract">
| > <forrest:property name="content-abstract"
| > nugget="get.abstract">
| > <jx:import
| > uri="cocoon://#{$cocoon/parameters/getRequest}.abstract.xml"/>
| > </forrest:property>
| > </forrest:properties>
| > </forrest:contract>
| >
| > If there is content to return into this content-abstract request then
that
| > is fine, on pages where there may not be any content available to
return,
| > then the contract is blank. This creates a <div class="abstract" /> . It
so
| > happens that most style sheets I looked at give the abstract div an
'italic'
| > font-style. Because the div is not closed properly, the rest of the
content
| > (content-main, content-minitoc-area etc.. ) that follows this
self-closed
| > div are also outputting the 'italic' font-style.
| >
| > I looked for ages as to why my main content was italic, its because I
have
| > no abtract-content in the xml source to give.
| >
| > I suppose one has to decide to either use a contract like this for all
pages
| > or for none.
|
| Why not check whether there is an abstract and if not omit the div?
| <xsl:if test="$content-abstract/div[@class='abstract']/*">
| <xsl:copy-of
| select="$content-abstract/div[@class='abstract']"/>
| </xsl:if>
You see, this is where I am still catching up with XSL, I didn't think
of solving it that way. Thanks. For the time being though, I moved
my abstract and am using it for something else at the moment. It might
be good to inlcude it somewhere as a commented out example.
Where should it go as an example ?
Gav...
|
| salu2
| --
| Thorsten Scherler
| COO Spain
| Wyona Inc. - Open Source Content Management - Apache Lenya
| http://www.wyona.com http://lenya.apache.org
| thorsten.scherler@wyona.com thorsten@apache.org
|
|
|
|
| --
| No virus found in this incoming message.
| Checked by AVG Free Edition.
| Version: 7.1.375 / Virus Database: 267.14.23/242 - Release Date:
26/01/2006
|
|
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.23/243 - Release Date: 27/01/2006
Re: Best way to add repeatable code in v2/v3 (was Re:
Exampleusecase)
Posted by Thorsten Scherler <th...@wyona.com>.
El vie, 27-01-2006 a las 17:59 +0800, Gav.... escribió:
> ----- Original Message -----
...
> |
> | Actually since Cyriaque and yourself seem to prefer that the default
> | behavior would be non enclosing divs we can change the default
> | behavior.
> |
> | wdyt?
>
> I have found another reason why it is best to close these divs properly.
>
> e.g.
>
> <forrest:contract name="content-abstract">
> <forrest:properties contract="content-abstract">
> <forrest:property name="content-abstract"
> nugget="get.abstract">
> <jx:import
> uri="cocoon://#{$cocoon/parameters/getRequest}.abstract.xml"/>
> </forrest:property>
> </forrest:properties>
> </forrest:contract>
>
> If there is content to return into this content-abstract request then that
> is fine, on pages where there may not be any content available to return,
> then the contract is blank. This creates a <div class="abstract" /> . It so
> happens that most style sheets I looked at give the abstract div an 'italic'
> font-style. Because the div is not closed properly, the rest of the content
> (content-main, content-minitoc-area etc.. ) that follows this self-closed
> div are also outputting the 'italic' font-style.
>
> I looked for ages as to why my main content was italic, its because I have
> no abtract-content in the xml source to give.
>
> I suppose one has to decide to either use a contract like this for all pages
> or for none.
Why not check whether there is an abstract and if not omit the div?
<xsl:if test="$content-abstract/div[@class='abstract']/*">
<xsl:copy-of
select="$content-abstract/div[@class='abstract']"/>
</xsl:if>
salu2
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
Re: Best way to add repeatable code in v2/v3 (was Re: Exampleusecase)
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Thorsten Scherler" <th...@apache.org>
To: <de...@forrest.apache.org>
Sent: Sunday, January 22, 2006 9:56 PM
Subject: Re: Best way to add repeatable code in v2/v3 (was Re:
Exampleusecase)
<snip >
| > | <forrest:hook name="headlines"></forrest:hook>
| > | creates
| > | <div id="headlines />
| > |
| > | and <forrest:hook name="headlines" nbsp="true"></forrest:hook>
| > | gives
| > | <div id="headlines"> </div>
| > |
| > | We need to document this in the howto, but self enclosing divs are
| > | default in the dispatcher, no bug!
| >
| > Thats fine, I will send in a patch to document this. I can not really
| > think of a situation (except in testing) where I would want an
| > empty div anyway, but came across it so mentioned it.
|
| Actually since Cyriaque and yourself seem to prefer that the default
| behavior would be non enclosing divs we can change the default
| behavior.
|
| wdyt?
I have found another reason why it is best to close these divs properly.
e.g.
<forrest:contract name="content-abstract">
<forrest:properties contract="content-abstract">
<forrest:property name="content-abstract"
nugget="get.abstract">
<jx:import
uri="cocoon://#{$cocoon/parameters/getRequest}.abstract.xml"/>
</forrest:property>
</forrest:properties>
</forrest:contract>
If there is content to return into this content-abstract request then that
is fine, on pages where there may not be any content available to return,
then the contract is blank. This creates a <div class="abstract" /> . It so
happens that most style sheets I looked at give the abstract div an 'italic'
font-style. Because the div is not closed properly, the rest of the content
(content-main, content-minitoc-area etc.. ) that follows this self-closed
div are also outputting the 'italic' font-style.
I looked for ages as to why my main content was italic, its because I have
no abtract-content in the xml source to give.
I suppose one has to decide to either use a contract like this for all pages
or for none.
Gav...
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.23/242 - Release Date: 26/01/2006
Re: Best way to add repeatable code in v2/v3 (was Re: Example
usecase)
Posted by Thorsten Scherler <th...@apache.org>.
El dom, 22-01-2006 a las 21:38 +0800, Gav.... escribió:
> ----- Original Message -----
> From: "Thorsten Scherler" <th...@apache.org>
> To: <de...@forrest.apache.org>
> Sent: Sunday, January 22, 2006 9:26 PM
> Subject: Re: Best way to add repeatable code in v2/v3 (was Re: Example
> usecase)
>
>
> | El dom, 22-01-2006 a las 21:09 +0800, Gav.... escribió:
> | ...
> | > |
> | > | > P.S-
> | > | >
> | > | > Creating an empty hook has the side effect of a self closing div -
> | > obviously
> | > | > inlvalid and messes
> | > | > up the rest of the page.
> | > |
> | > | Raise an issue (if there isn't one already, this is ringing a bell
> | > | somewhere in the deep recesses of my mind).
> | >
> | > I will raise an issue, I had a good look for one but could not
> | > find a relevent one.
> |
> | Hmm, did you read the other mail I wrote?
>
> Yes, I posted this earlier than that one arrived though.
>
> |
> |
> forrest-trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/resources/stylesheets/hooksMatcher.xsl
> | ...
> | <xsl:if test="@nbsp='true'"> </xsl:if>
> | ...
> |
> | Meaning
> | <forrest:hook name="headlines"></forrest:hook>
> | creates
> | <div id="headlines />
> |
> | and <forrest:hook name="headlines" nbsp="true"></forrest:hook>
> | gives
> | <div id="headlines"> </div>
> |
> | We need to document this in the howto, but self enclosing divs are
> | default in the dispatcher, no bug!
>
> Thats fine, I will send in a patch to document this. I can not really
> think of a situation (except in testing) where I would want an
> empty div anyway, but came across it so mentioned it.
Actually since Cyriaque and yourself seem to prefer that the default
behavior would be non enclosing divs we can change the default
behavior.
wdyt?
>
> I did see the resolution you mention in the whiteboard and on list [1]
> but wasn't sure of the final outcome.
>
> Thanks. Now if you could point me in the right direction regarding
> the subject title ;>)
jeje, yeah, after I fixed the httpd bug on lenya.zones.
salu2
>
> [1] -
> http://mail-archives.apache.org/mod_mbox/forrest-dev/200507.mbox/%3C42EA35BD.5080008@pcotech.fr%3E
>
> Gav...
>
> |
> | salu2
> | --
> | thorsten
> |
> | "Together we stand, divided we fall!"
> | Hey you (Pink Floyd)
> |
> |
> |
> |
> | --
> | No virus found in this incoming message.
> | Checked by AVG Free Edition.
> | Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date:
> 20/01/2006
> |
> |
>
>
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Best way to add repeatable code in v2/v3 (was Re: Example usecase)
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Thorsten Scherler" <th...@apache.org>
To: <de...@forrest.apache.org>
Sent: Sunday, January 22, 2006 9:26 PM
Subject: Re: Best way to add repeatable code in v2/v3 (was Re: Example
usecase)
| El dom, 22-01-2006 a las 21:09 +0800, Gav.... escribió:
| ...
| > |
| > | > P.S-
| > | >
| > | > Creating an empty hook has the side effect of a self closing div -
| > obviously
| > | > inlvalid and messes
| > | > up the rest of the page.
| > |
| > | Raise an issue (if there isn't one already, this is ringing a bell
| > | somewhere in the deep recesses of my mind).
| >
| > I will raise an issue, I had a good look for one but could not
| > find a relevent one.
|
| Hmm, did you read the other mail I wrote?
Yes, I posted this earlier than that one arrived though.
|
|
forrest-trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/resources/stylesheets/hooksMatcher.xsl
| ...
| <xsl:if test="@nbsp='true'"> </xsl:if>
| ...
|
| Meaning
| <forrest:hook name="headlines"></forrest:hook>
| creates
| <div id="headlines />
|
| and <forrest:hook name="headlines" nbsp="true"></forrest:hook>
| gives
| <div id="headlines"> </div>
|
| We need to document this in the howto, but self enclosing divs are
| default in the dispatcher, no bug!
Thats fine, I will send in a patch to document this. I can not really
think of a situation (except in testing) where I would want an
empty div anyway, but came across it so mentioned it.
I did see the resolution you mention in the whiteboard and on list [1]
but wasn't sure of the final outcome.
Thanks. Now if you could point me in the right direction regarding
the subject title ;>)
[1] -
http://mail-archives.apache.org/mod_mbox/forrest-dev/200507.mbox/%3C42EA35BD.5080008@pcotech.fr%3E
Gav...
|
| salu2
| --
| thorsten
|
| "Together we stand, divided we fall!"
| Hey you (Pink Floyd)
|
|
|
|
| --
| No virus found in this incoming message.
| Checked by AVG Free Edition.
| Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date:
20/01/2006
|
|
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date: 20/01/2006
Re: Best way to add repeatable code in v2/v3 (was Re: Example use
case)
Posted by Thorsten Scherler <th...@apache.org>.
El dom, 22-01-2006 a las 21:09 +0800, Gav.... escribió:
...
> |
> | > P.S-
> | >
> | > Creating an empty hook has the side effect of a self closing div -
> obviously
> | > inlvalid and messes
> | > up the rest of the page.
> |
> | Raise an issue (if there isn't one already, this is ringing a bell
> | somewhere in the deep recesses of my mind).
>
> I will raise an issue, I had a good look for one but could not
> find a relevent one.
Hmm, did you read the other mail I wrote?
forrest-trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/resources/stylesheets/hooksMatcher.xsl
...
<xsl:if test="@nbsp='true'"> </xsl:if>
...
Meaning
<forrest:hook name="headlines"></forrest:hook>
creates
<div id="headlines />
and <forrest:hook name="headlines" nbsp="true"></forrest:hook>
gives
<div id="headlines"> </div>
We need to document this in the howto, but self enclosing divs are
default in the dispatcher, no bug!
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Best way to add repeatable code in v2/v3 (was Re: Example use case)
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Ross Gardler" <rg...@apache.org>
To: <de...@forrest.apache.org>
Sent: Sunday, January 22, 2006 2:00 AM
Subject: [spam score=82%] Re: Best way to add repeatable code in v2/v3 (was
Re: Example use case)
| Gav.... wrote:
| > Hi All,
| >
| > On the right hand side of http://minitutorials.com I have some
'headlines'
| > in a 'headlines' div
| > All boxes are in a 'rightbar' div also.
| > The code for this is in One file called rightnav.ssi and included using
| > either 'include' or 'require'
| > This obviously has the effect that all of the site pages get the content
| > from the one file.
|
| ...
|
| > 3. The html code required I transfered from rightnav.ssi into
rightnav.html
| > and put this file
| > into xdocs directory. I am hoping that the <url>/rightbar.html</url> is
| > therefore correct.
| >
| > 4. Didn't see what else I would need to do, so did a 'forrest run' , did
not
| > show up.
| > Also did a ForrestBot onto the web server, also does not show up.
| >
| > So, this did not work, the question is, have I done something wrong,
missed
| > something out
| > or is there a different/better way to include content into the
'headlines'
| > hook ?
|
| I've not checked your syntax as I am not familiar enough with these
| contracts to see it without cross-checking with the documentation, which
| I assume you have done. Others will be better at spotting syntax errors.
It seems correct from the docs I could find. The docs do specify that
the included file needs to be a forrest generated html source file. Putting
in rightnav.html into xdocs doesn't seem to be enough, as it is not being
linked to from anywhere (apart from this contract), then I guess it is
not being generated - a rightnav.html does not get reproduced into
a generated site.
|
| Assuming syntax is correct. Have you verified that requesting
| "http://localhost:8888/rightbar.html" actually returns some code?
No it doesn't, I get a can not find rightbar.xml error
|
| The other thing is that I wrote this contract for V1. There have been
| many changes since then, including the use of JX. I'm not sure if this
| is still the "right" way to include content.
It seems most of the newer contracts are using JX, maybe v2/v3 need
it to be this way. Any mention of JX on the forrest site says to refer
to cocoon docs for howto's , I don't really want to start wandering
in that direction though.
|
| > Alternative I thought of would be to create a contract for it. Although
I
| > can see how to
| > create a contract, not sure again on the best way of approaching it.
Maybe
| > doing a similar
| > thing as including the body from say index.xml but using
| > rightnavcontent.xml, use jx: ??
|
| See above - we need a views savvy dev to advise here.
Good idea, I'll wait for them to wake up and flood the list :)
|
| > (Re-reading the above, I see at least (at last ?) I have suggestions,
so
| > must be learning something!)
|
| :-) and you're teaching those of us still trying to get to grips with
| views (when I taught at Universities I always used to learn loads by
| doing the labs when students would ask me why their code behaved this
| way or that way).
|
| > P.S-
| >
| > Creating an empty hook has the side effect of a self closing div -
obviously
| > inlvalid and messes
| > up the rest of the page.
|
| Raise an issue (if there isn't one already, this is ringing a bell
| somewhere in the deep recesses of my mind).
I will raise an issue, I had a good look for one but could not
find a relevent one.
Gav...
|
| Ross
|
|
| --
| No virus found in this incoming message.
| Checked by AVG Free Edition.
| Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date:
20/01/2006
|
|
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date: 20/01/2006
Re: Best way to add repeatable code in v2/v3 (was Re: Example use
case)
Posted by Ross Gardler <rg...@apache.org>.
Gav.... wrote:
> Hi All,
>
> On the right hand side of http://minitutorials.com I have some 'headlines'
> in a 'headlines' div
> All boxes are in a 'rightbar' div also.
> The code for this is in One file called rightnav.ssi and included using
> either 'include' or 'require'
> This obviously has the effect that all of the site pages get the content
> from the one file.
...
> 3. The html code required I transfered from rightnav.ssi into rightnav.html
> and put this file
> into xdocs directory. I am hoping that the <url>/rightbar.html</url> is
> therefore correct.
>
> 4. Didn't see what else I would need to do, so did a 'forrest run' , did not
> show up.
> Also did a ForrestBot onto the web server, also does not show up.
>
> So, this did not work, the question is, have I done something wrong, missed
> something out
> or is there a different/better way to include content into the 'headlines'
> hook ?
I've not checked your syntax as I am not familiar enough with these
contracts to see it without cross-checking with the documentation, which
I assume you have done. Others will be better at spotting syntax errors.
Assuming syntax is correct. Have you verified that requesting
"http://localhost:8888/rightbar.html" actually returns some code?
The other thing is that I wrote this contract for V1. There have been
many changes since then, including the use of JX. I'm not sure if this
is still the "right" way to include content.
> Alternative I thought of would be to create a contract for it. Although I
> can see how to
> create a contract, not sure again on the best way of approaching it. Maybe
> doing a similar
> thing as including the body from say index.xml but using
> rightnavcontent.xml, use jx: ??
See above - we need a views savvy dev to advise here.
> (Re-reading the above, I see at least (at last ?) I have suggestions, so
> must be learning something!)
:-) and you're teaching those of us still trying to get to grips with
views (when I taught at Universities I always used to learn loads by
doing the labs when students would ask me why their code behaved this
way or that way).
> P.S-
>
> Creating an empty hook has the side effect of a self closing div - obviously
> inlvalid and messes
> up the rest of the page.
Raise an issue (if there isn't one already, this is ringing a bell
somewhere in the deep recesses of my mind).
Ross
Re: character entities
Posted by Thorsten Scherler <th...@apache.org>.
El mié, 25-01-2006 a las 16:34 +0800, Gav.... escribió:
> -
...
> |
> | Jeje, nice theory, but I have an example where you do not combine  
> | with " and still the described behavior can be seen.
> |
> | <forrest:hook class="breadtrail">
> | <forrest:contract name="genericMarkup">
> | <forrest:properties contract="genericMarkup">
> | <forrest:property name="genericMarkup">
> | <strong> </strong>
> | </forrest:property>
> | </forrest:properties>
> | </forrest:contract>
> | </forrest:hook>
>
> Yes, it was a theory, it was late also.
> What does a strong space look like :)
>
lol It is a trick, because the genericMarkup contract is expecting
markup and not single strings. ;-)
> |
> |
> | >
> | > Anyway, in the example contract code above, removing   and putting
> a
> | > real space in there cures it and the space
> | > is preserved no problem as it is enclosed between the quotes.
> | >
> | > I copied the contract to my /pili/html/ directory and it now renders
> | > correctly.
> | >
> | > Have I missed something here or was it that simple ?
> | >
> |
> | Actually regarding http://www.html-world.de/program/html_sz.php
> | Unicode:
> | XML:  
> | Result: space
> |
> | We are using the right code for spaces. I guess you need to set the
> | locale to UTF-8 on the server (before starting httpd), since forrest is
> | rendering it on lenya.zones just fine but the httpd is delivering the
> | content with "Â".
>
> I am not disputing that   is a space, my argument and what my
> solution above was that you need not employ   all the time -
> especially when text is surrounded by quotes.
>
> The example text is :-
>
> ("<i18n:text >Last Published:</i18n:text> " + document.lastModified);
>
> The   is there to put a space between the : and the date produced by
> document.lastModified. I do not see a reason for using   in this case
> the same as there is no   between the words 'Last' and 'Published'
>
> What works for me is :-
>
> ("<i18n:text >Last Published:</i18n:text> " + document.lastModified);
>
> That 'space' is legal and universal, it is enclosed in quotes and so will
> get converted correctly no matter how the locale is set on the server.
>
> Also for some, there will definatly be problems in getting their web server
> locale changed. I can change my locale on my server no problem, however
> apache.minitutorials.com and some of my other sites are remotely hosted
> by different ISPs, I doubt they will change on my say so. I guess this to
> be true of many Forrest users.
Yeah, you are right for above contract or any other xsl based code where
you always have the solution of <xsl:text> </xsl:text> or the one you
described, but the problem is actually bigger then this. Like seen in
the "strong space" example, you may want a single space in some hooks or
better in the structurer.
I can understand that some server are out of control and the
configuration may be given, but as David points out normally you can
control it via .htaccess which all ISP should allow.
I do not know atm a simple solution but I know that the source of
http://lenya.zones.apache.org/index.html on the servers DOC_ROOT looks
like:
<?xml version="1.0" encoding="UTF-8"?>
...
<div id="publishedStrip">
<script type="text/javascript">document.write("Today: " + new
Date());</script>
</div>
...and looking on the source code of above link I can find:
<?xml version="1.0" encoding="UTF-8"?>
...
<div id="publishedStrip">
<script type="text/javascript">document.write("Today:Â " + new
Date());</script>
</div>
Now the question is who to blame that the encoding is ignored? Like
stated above in some situation (e.g. not based on xsl) you need to use
the *right* way for defining spaces in utf-8 ( ), what about this
situations?
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: character entities
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Thorsten Scherler" <th...@apache.org>
To: <de...@forrest.apache.org>
Sent: Sunday, January 22, 2006 8:35 PM
Subject: Re: character entities
| El sáb, 21-01-2006 a las 22:41 +0800, Gav.... escribió:
| > I wrote earlier :-
| >
| > | P.S-
| > |
| > | Creating an empty hook has the side effect of a self closing div -
| > obviously
| > | inlvalid and messes
| > | up the rest of the page.
| > |
| > | e.g.
| > |
| > | <forrest:hook name="headlines"></forrest:hook>
| > | creates
| > | <div id="headlines />
| > | instead of
| > | <div id="headlines"></div>
| > |
| >
| > This made me have a look around, and as a side-effect found an old
| > thread regarding this back in July 2005, just before my time I think.
| >
| > The discussion also brought up   and its possible side effects
| > of creating  .
|
| Yeah, I am running into the same problem ATM. You can see it online at
| http://lenya.zones.apache.org/ "Today:Â..." (I am looking right now to
| fix that, so the site may be fixed if you visit it)
|
| On my local machine that does not happen. I have run into a similar
| problem with cocoon on a job I did a while ago. The problem was lying in
| the server configuration, now I just looked on our zones server:
| Sun Microsystems Inc. SunOS 5.10 Generic January 2005
| -bash-3.00$ locale
| LANG=
| LC_CTYPE="C"
| LC_NUMERIC="C"
| LC_TIME="C"
| LC_COLLATE="C"
| LC_MONETARY="C"
| LC_MESSAGES="C"
| LC_ALL=
|
| The locale is not UTF-8!
|
| Doing "locale" on my machine gives:
| LANG=es_ES.UTF-8
| LC_CTYPE="es_ES.UTF-8"
| LC_NUMERIC="es_ES.UTF-8"
| LC_TIME="es_ES.UTF-8"
| LC_COLLATE="es_ES.UTF-8"
| LC_MONETARY="es_ES.UTF-8"
| LC_MESSAGES="es_ES.UTF-8"
| LC_PAPER="es_ES.UTF-8"
| LC_NAME="es_ES.UTF-8"
| LC_ADDRESS="es_ES.UTF-8"
| LC_TELEPHONE="es_ES.UTF-8"
| LC_MEASUREMENT="es_ES.UTF-8"
| LC_IDENTIFICATION="es_ES.UTF-8"
| LC_ALL=
|
| That is UTF-8!
|
| The solution back on the job was setting the language to de_DE.UTF-8
| before starting the tomcat server.
|
| >
| > I am seeing  a lot lately and so think the problem is still not solved.
|
| Yeah, we need to find the root cause of this problem. I guess it is
| lying in the "locale".
|
| > For instance it is the result of siteinfo-last-published.ft.
| >
| > Last Published:Â 01/21/2006 17:53:37
| >
| > This line is created from the contract here :-
| >
| > <xsl:template name="siteinfo-last-published-body">
| > <script type="text/javascript">document.write("<i18n:text >Last
| > Published:</i18n:text> " + document.lastModified);</script>
| > </xsl:template>
| >
| > I have a theory.
| >
| > in the code the   is right next to a " (quote). The entity number
for "
| > (quote) is "
| >
| > I had a crazy thought that maybe they were adding together somehow.
| > (160+34=194)
| >
| >   + " = Â
| >
| > Guess what  is equal to , yup :-
| >
| > Â
|
| Jeje, nice theory, but I have an example where you do not combine  
| with " and still the described behavior can be seen.
|
| <forrest:hook class="breadtrail">
| <forrest:contract name="genericMarkup">
| <forrest:properties contract="genericMarkup">
| <forrest:property name="genericMarkup">
| <strong> </strong>
| </forrest:property>
| </forrest:properties>
| </forrest:contract>
| </forrest:hook>
Yes, it was a theory, it was late also.
What does a strong space look like :)
|
|
| >
| > Anyway, in the example contract code above, removing   and putting
a
| > real space in there cures it and the space
| > is preserved no problem as it is enclosed between the quotes.
| >
| > I copied the contract to my /pili/html/ directory and it now renders
| > correctly.
| >
| > Have I missed something here or was it that simple ?
| >
|
| Actually regarding http://www.html-world.de/program/html_sz.php
| Unicode:
| XML:  
| Result: space
|
| We are using the right code for spaces. I guess you need to set the
| locale to UTF-8 on the server (before starting httpd), since forrest is
| rendering it on lenya.zones just fine but the httpd is delivering the
| content with "Â".
I am not disputing that   is a space, my argument and what my
solution above was that you need not employ   all the time -
especially when text is surrounded by quotes.
The example text is :-
("<i18n:text >Last Published:</i18n:text> " + document.lastModified);
The   is there to put a space between the : and the date produced by
document.lastModified. I do not see a reason for using   in this case
the same as there is no   between the words 'Last' and 'Published'
What works for me is :-
("<i18n:text >Last Published:</i18n:text> " + document.lastModified);
That 'space' is legal and universal, it is enclosed in quotes and so will
get converted correctly no matter how the locale is set on the server.
Also for some, there will definatly be problems in getting their web server
locale changed. I can change my locale on my server no problem, however
apache.minitutorials.com and some of my other sites are remotely hosted
by different ISPs, I doubt they will change on my say so. I guess this to
be true of many Forrest users.
Gav...
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.22/239 - Release Date: 24/01/2006
Re: character entities
Posted by Thorsten Scherler <th...@apache.org>.
El sáb, 21-01-2006 a las 22:41 +0800, Gav.... escribió:
> I wrote earlier :-
>
> | P.S-
> |
> | Creating an empty hook has the side effect of a self closing div -
> obviously
> | inlvalid and messes
> | up the rest of the page.
> |
> | e.g.
> |
> | <forrest:hook name="headlines"></forrest:hook>
> | creates
> | <div id="headlines />
> | instead of
> | <div id="headlines"></div>
> |
>
> This made me have a look around, and as a side-effect found an old
> thread regarding this back in July 2005, just before my time I think.
>
> The discussion also brought up   and its possible side effects
> of creating  .
Yeah, I am running into the same problem ATM. You can see it online at
http://lenya.zones.apache.org/ "Today:Â..." (I am looking right now to
fix that, so the site may be fixed if you visit it)
On my local machine that does not happen. I have run into a similar
problem with cocoon on a job I did a while ago. The problem was lying in
the server configuration, now I just looked on our zones server:
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
-bash-3.00$ locale
LANG=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
The locale is not UTF-8!
Doing "locale" on my machine gives:
LANG=es_ES.UTF-8
LC_CTYPE="es_ES.UTF-8"
LC_NUMERIC="es_ES.UTF-8"
LC_TIME="es_ES.UTF-8"
LC_COLLATE="es_ES.UTF-8"
LC_MONETARY="es_ES.UTF-8"
LC_MESSAGES="es_ES.UTF-8"
LC_PAPER="es_ES.UTF-8"
LC_NAME="es_ES.UTF-8"
LC_ADDRESS="es_ES.UTF-8"
LC_TELEPHONE="es_ES.UTF-8"
LC_MEASUREMENT="es_ES.UTF-8"
LC_IDENTIFICATION="es_ES.UTF-8"
LC_ALL=
That is UTF-8!
The solution back on the job was setting the language to de_DE.UTF-8
before starting the tomcat server.
>
> I am seeing  a lot lately and so think the problem is still not solved.
Yeah, we need to find the root cause of this problem. I guess it is
lying in the "locale".
> For instance it is the result of siteinfo-last-published.ft.
>
> Last Published:Â 01/21/2006 17:53:37
>
> This line is created from the contract here :-
>
> <xsl:template name="siteinfo-last-published-body">
> <script type="text/javascript">document.write("<i18n:text >Last
> Published:</i18n:text> " + document.lastModified);</script>
> </xsl:template>
>
> I have a theory.
>
> in the code the   is right next to a " (quote). The entity number for "
> (quote) is "
>
> I had a crazy thought that maybe they were adding together somehow.
> (160+34=194)
>
>   + " = Â
>
> Guess what  is equal to , yup :-
>
> Â
Jeje, nice theory, but I have an example where you do not combine  
with " and still the described behavior can be seen.
<forrest:hook class="breadtrail">
<forrest:contract name="genericMarkup">
<forrest:properties contract="genericMarkup">
<forrest:property name="genericMarkup">
<strong> </strong>
</forrest:property>
</forrest:properties>
</forrest:contract>
</forrest:hook>
>
> Anyway, in the example contract code above, removing   and putting a
> real space in there cures it and the space
> is preserved no problem as it is enclosed between the quotes.
>
> I copied the contract to my /pili/html/ directory and it now renders
> correctly.
>
> Have I missed something here or was it that simple ?
>
Actually regarding http://www.html-world.de/program/html_sz.php
Unicode:
XML:  
Result: space
We are using the right code for spaces. I guess you need to set the
locale to UTF-8 on the server (before starting httpd), since forrest is
rendering it on lenya.zones just fine but the httpd is delivering the
content with "Â".
More information about utf-8 and unicode can be found on [1]. How to set
it in Gentoo [2] is in spanish only but I reckon you still can get the
idea following the coding examples. Finally [3] a smaller howto in
english.
> Still looking into the empty <div> problem but again may be   related
> I'm not sure.
No, IMO not, see above.
> There was talk in the archives it was cured, but seems to be back.
>
forrest-trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/resources/stylesheets/hooksMatcher.xsl
...
<xsl:if test="@nbsp='true'"> </xsl:if>
...
Meaning
<forrest:hook name="headlines"></forrest:hook>
creates
<div id="headlines />
and <forrest:hook name="headlines" nbsp="true"></forrest:hook>
gives
<div id="headlines"> </div>
We need to document this in the howto.
HTH
salu2
[1]http://www.cl.cam.ac.uk/~mgk25/unicode.html
[2]http://es.gentoo-wiki.com/Unicode-UTF-8
[3]http://www.linux.com/howtos/Indic-Fonts-HOWTO/locale.shtml
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
character entities
Posted by "Gav...." <br...@brightontown.com.au>.
I wrote earlier :-
| P.S-
|
| Creating an empty hook has the side effect of a self closing div -
obviously
| inlvalid and messes
| up the rest of the page.
|
| e.g.
|
| <forrest:hook name="headlines"></forrest:hook>
| creates
| <div id="headlines />
| instead of
| <div id="headlines"></div>
|
This made me have a look around, and as a side-effect found an old
thread regarding this back in July 2005, just before my time I think.
The discussion also brought up   and its possible side effects
of creating  .
I am seeing  a lot lately and so think the problem is still not solved.
For instance it is the result of siteinfo-last-published.ft.
Last Published:Â 01/21/2006 17:53:37
This line is created from the contract here :-
<xsl:template name="siteinfo-last-published-body">
<script type="text/javascript">document.write("<i18n:text >Last
Published:</i18n:text> " + document.lastModified);</script>
</xsl:template>
I have a theory.
in the code the   is right next to a " (quote). The entity number for "
(quote) is "
I had a crazy thought that maybe they were adding together somehow.
(160+34=194)
  + " = Â
Guess what  is equal to , yup :-
Â
Anyway, in the example contract code above, removing   and putting a
real space in there cures it and the space
is preserved no problem as it is enclosed between the quotes.
I copied the contract to my /pili/html/ directory and it now renders
correctly.
Have I missed something here or was it that simple ?
Still looking into the empty <div> problem but again may be   related
I'm not sure.
There was talk in the archives it was cured, but seems to be back.
HTH
Gav...
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date: 20/01/2006
Best way to add repeatable code in v2/v3 (was Re: Example use case)
Posted by "Gav...." <br...@brightontown.com.au>.
Hi All,
On the right hand side of http://minitutorials.com I have some 'headlines'
in a 'headlines' div
All boxes are in a 'rightbar' div also.
The code for this is in One file called rightnav.ssi and included using
either 'include' or 'require'
This obviously has the effect that all of the site pages get the content
from the one file.
I have been looking at how to do this using dispatcher method.
What I have tried :-
1. Create Hooks as required to get the div and css to position it.
<forrest:hook name="headlines">
<forrest:hook name="rightbar">
<forrest:contract name="search-input">
<forrest:properties contract="search-input">
<forrest:property name="search-input">
<search name="minitutorials" domain="www.minitutorials.com"
provider="google"/>
</forrest:property>
</forrest:properties>
</forrest:contract>
</forrest:hook>
</forrest:hook>
As you can see I have added a search-input so the div shows on the site and
is present at http://apache.minitutorials.com
2. Then I looked through ls.contracts and found one I thought might be
suitable as replacement of 'include/require'
Adding the code for it into my hooks above I ended up with :-
<forrest:hook name="headlines">
<forrest:hook name="rightbar">
<forrest:contract name="search-input">
<forrest:properties contract="search-input">
<forrest:property name="search-input">
<search name="minitutorials" domain="www.minitutorials.com"
provider="google"/>
</forrest:property>
</forrest:properties>
</forrest:contract>
<forrest:contract name="content-include-html">
<forrest:properties contract="content-include-html">
<forrest:property name="content-include-html"
nugget="get.nugget.include.html">
<url>/rightbar.html</url>
</forrest:property>
</forrest:properties>
</forrest:contract>
</forrest:hook>
</forrest:hook>
(content-include sounds just what I need)
3. The html code required I transfered from rightnav.ssi into rightnav.html
and put this file
into xdocs directory. I am hoping that the <url>/rightbar.html</url> is
therefore correct.
4. Didn't see what else I would need to do, so did a 'forrest run' , did not
show up.
Also did a ForrestBot onto the web server, also does not show up.
So, this did not work, the question is, have I done something wrong, missed
something out
or is there a different/better way to include content into the 'headlines'
hook ?
Alternative I thought of would be to create a contract for it. Although I
can see how to
create a contract, not sure again on the best way of approaching it. Maybe
doing a similar
thing as including the body from say index.xml but using
rightnavcontent.xml, use jx: ??
I am sure I am missing the obvious, a pointer would be great :)
(Re-reading the above, I see at least (at last ?) I have suggestions, so
must be learning something!)
P.S-
Creating an empty hook has the side effect of a self closing div - obviously
inlvalid and messes
up the rest of the page.
e.g.
<forrest:hook name="headlines"></forrest:hook>
creates
<div id="headlines />
instead of
<div id="headlines"></div>
Gav...
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date: 20/01/2006
Re: Example use case.
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Ross Gardler" <rg...@apache.org>
To: <de...@forrest.apache.org>
Sent: Friday, January 20, 2006 6:59 PM
Subject: Re: Example use case.
|
| For an example of creating your own theme see the o.a.f.themer.Coat
| plugin in whiteboard. Don't be fooled by the fact that this looks like a
| plugin, at present it is nothing more than a site that uses a new theme.
| I still have to do a little work to make it an installable theme - I'm
| waiting to see the necessary changes for v3.
|
| Ross
Thanks, I'd forgotten about that, I think I even sent in a CSS patch
regarding the footer at one stage. Will take another look
Gav...
|
|
| --
| No virus found in this incoming message.
| Checked by AVG Free Edition.
| Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date:
19/01/2006
|
|
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date: 19/01/2006
Re: Example use case.
Posted by Ross Gardler <rg...@apache.org>.
Gav.... wrote:
> ----- Original Message -----
> From: "Ross Gardler" <rg...@apache.org>
> To: <de...@forrest.apache.org>
> Sent: Friday, January 20, 2006 7:51 AM
> Subject: Re: Example use case.
>
>
> | Gav.... wrote:
> |
> | This is whole thing getting confusing. It feels like you are trying to
> | solve all problems at once, and as a result are being recommended to
> | approach it with a whole raft of technologies.
>
> Ok, I agree, but all the answers have helped.
>
> | Lets take it one step at a time. Here are the major tasks:
> |
> | 1) get a theme that you like
>
> Back to using v2, this is the stage where I am at.
>
> I have followed the Dispatcher Quickstart guide to the letter
> and it works perfectly (forgets to mention to add
> project.theme-extension=.fv
> to forrest.properties) . So this I have completed no problem.
Patches to the doc are welcome, especially if you are able to highlight
some of the forthcoming changes in v3.
> Now, instead of altering pelt.fv I thought I would instead copy it
> and call it pili.fv, saving in the same folder as pelt.fv.
> I then rename project.theme=pili in project.properties.
> re-run forrest run and I get Internal Server Error with :-
>
> "ElemTemplateElement error: Found more than one template named: noFt-body"
>
> So I guess I cant create my own named theme just yet, or I missed something
> not documented maybe. I will alter pelt.fv in the meantime.
For an example of creating your own theme see the o.a.f.themer.Coat
plugin in whiteboard. Don't be fooled by the fact that this looks like a
plugin, at present it is nothing more than a site that uses a new theme.
I still have to do a little work to make it an installable theme - I'm
waiting to see the necessary changes for v3.
Ross
Re: Example use case.
Posted by David Crossley <cr...@apache.org>.
Gav.... wrote:
>
> I have followed the Dispatcher Quickstart guide to the letter
> and it works perfectly (forgets to mention to add
> project.theme-extension=.fv
> to forrest.properties) . So this I have completed no problem.
That is the default, so no need to declare it.
-David
Re: Example use case.
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Ross Gardler" <rg...@apache.org>
To: <de...@forrest.apache.org>
Sent: Friday, January 20, 2006 7:51 AM
Subject: Re: Example use case.
| Gav.... wrote:
|
| This is whole thing getting confusing. It feels like you are trying to
| solve all problems at once, and as a result are being recommended to
| approach it with a whole raft of technologies.
Ok, I agree, but all the answers have helped.
| Lets take it one step at a time. Here are the major tasks:
|
| 1) get a theme that you like
Back to using v2, this is the stage where I am at.
I have followed the Dispatcher Quickstart guide to the letter
and it works perfectly (forgets to mention to add
project.theme-extension=.fv
to forrest.properties) . So this I have completed no problem.
Now, instead of altering pelt.fv I thought I would instead copy it
and call it pili.fv, saving in the same folder as pelt.fv.
I then rename project.theme=pili in project.properties.
re-run forrest run and I get Internal Server Error with :-
"ElemTemplateElement error: Found more than one template named: noFt-body"
So I guess I cant create my own named theme just yet, or I missed something
not documented maybe. I will alter pelt.fv in the meantime.
| 2) get the content (without navigation) in your desired input format
| 3) get the navigation sections to work (either by integrating your
| existing systems or starting afresh)
|
| Lets tackle one of these at a time. It doesn't matter, from a technical
| perspective, which you do first (and hence those of us who understand
| Forrest inside out throw out all these technologies all at once). For a
| slow introduction I would recommend doing it in the order noted above.
|
| You can work on the theme part by taking a sample site and modifying the
| theme and bringing your CSS into it (I see in another thread you are
| already starting to do this).
Using seed-sample and building from that.
Thanks
Gav...
|
| Ross
|
|
| --
| No virus found in this incoming message.
| Checked by AVG Free Edition.
| Version: 7.1.375 / Virus Database: 267.14.20/234 - Release Date:
18/01/2006
|
|
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date: 19/01/2006
Re: Example use case.
Posted by Ross Gardler <rg...@apache.org>.
Gav.... wrote:
> ----- Original Message -----
> From: "Ross Gardler" <rg...@apache.org>
> To: <de...@forrest.apache.org>
> Sent: Friday, January 20, 2006 7:51 AM
> Subject: Re: Example use case.
>
>
> | Gav.... wrote:
> |
> | This is whole thing getting confusing. It feels like you are trying to
> | solve all problems at once, and as a result are being recommended to
> | approach it with a whole raft of technologies.
> |
> | Lets take it one step at a time. Here are the major tasks:
> |
> | 1) get a theme that you like
> | 2) get the content (without navigation) in your desired input format
> | 3) get the navigation sections to work (either by integrating your
> | existing systems or starting afresh)
> |
> | Lets tackle one of these at a time. It doesn't matter, from a technical
> | perspective, which you do first (and hence those of us who understand
> | Forrest inside out throw out all these technologies all at once). For a
> | slow introduction I would recommend doing it in the order noted above.
> |
> | You can work on the theme part by taking a sample site and modifying the
> | theme and bringing your CSS into it (I see in another thread you are
> | already starting to do this).
>
>
> Ok, so now I can cross off number 1) , I have a working theme.
>
> Now onto 2) , get the content.
>
> What are peoples opinions on getting the content from my old site
> onto the new rc1 version, based on converting around 90 html pages.
>
> I do not mind converting to forrest source xml if consensus is that is
> what is best. But is there a way of automating this, or is it a do it
> by hand type of job?
There is no real need to convert all source file, Forrest can work with
HTML as a source. Although you should be aware of one or two issues with
the html-to-document.xsl, most common stumbling block is that headings
have to be correctly sequenced.
However, in writing out the steps involved in this I realised that in
the above list of tasks we have 2) and 3) the wrong way around. We can't
generate the whole site until we have the navigation working. SO it
looks like we are working on 3 (navigation) not 2 (content)
There are three approaches to this. I'm not sure which is the most
appropriate to your use case:
1) Write a contract, based on the current navigation contract, that will
use your existing navigation document and render it for the site
- I don't like this approach as it makes the contract responsible for
converting the source format and therefore limits reuse of your contract
and you will not be able to easily reuse new navigation contracts.
2) Write an plugin that will convert your existing format to site.xml
(see the IMSManifest plugin for an example) and use the existing
navigation contracts
- I like this one because you will be able reuse current contracts
and others will be able to reuse contracts you build for your site
3) Manually convert your current navigation document to site.xml
- may be easier if you only have a single, relatively small nav document
Ross
Re: Example use case.
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Ross Gardler" <rg...@apache.org>
To: <de...@forrest.apache.org>
Sent: Friday, January 20, 2006 7:51 AM
Subject: Re: Example use case.
| Gav.... wrote:
|
| This is whole thing getting confusing. It feels like you are trying to
| solve all problems at once, and as a result are being recommended to
| approach it with a whole raft of technologies.
|
| Lets take it one step at a time. Here are the major tasks:
|
| 1) get a theme that you like
| 2) get the content (without navigation) in your desired input format
| 3) get the navigation sections to work (either by integrating your
| existing systems or starting afresh)
|
| Lets tackle one of these at a time. It doesn't matter, from a technical
| perspective, which you do first (and hence those of us who understand
| Forrest inside out throw out all these technologies all at once). For a
| slow introduction I would recommend doing it in the order noted above.
|
| You can work on the theme part by taking a sample site and modifying the
| theme and bringing your CSS into it (I see in another thread you are
| already starting to do this).
Ok, so now I can cross off number 1) , I have a working theme.
Now onto 2) , get the content.
What are peoples opinions on getting the content from my old site
onto the new rc1 version, based on converting around 90 html pages.
I do not mind converting to forrest source xml if consensus is that is
what is best. But is there a way of automating this, or is it a do it
by hand type of job?
Thanks
Gav..
|
| Ross
|
|
| --
| No virus found in this incoming message.
| Checked by AVG Free Edition.
| Version: 7.1.375 / Virus Database: 267.14.20/234 - Release Date:
18/01/2006
|
|
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.2/251 - Release Date: 4/02/2006
Re: Example use case.
Posted by Ross Gardler <rg...@apache.org>.
Gav.... wrote:
This is whole thing getting confusing. It feels like you are trying to
solve all problems at once, and as a result are being recommended to
approach it with a whole raft of technologies.
Lets take it one step at a time. Here are the major tasks:
1) get a theme that you like
2) get the content (without navigation) in your desired input format
3) get the navigation sections to work (either by integrating your
existing systems or starting afresh)
Lets tackle one of these at a time. It doesn't matter, from a technical
perspective, which you do first (and hence those of us who understand
Forrest inside out throw out all these technologies all at once). For a
slow introduction I would recommend doing it in the order noted above.
You can work on the theme part by taking a sample site and modifying the
theme and bringing your CSS into it (I see in another thread you are
already starting to do this).
Ross
Re: Example use case.
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Thorsten Scherler" <th...@apache.org>
To: <de...@forrest.apache.org>
Sent: Thursday, January 19, 2006 11:13 PM
Subject: Re: Example use case.
| El jue, 19-01-2006 a las 19:28 +0800, Gav.... escribió:
| > ----- Original Message -----
| > From: "David Crossley" <cr...@apache.org>
| > To: <de...@forrest.apache.org>
| > Sent: Thursday, January 19, 2006 12:39 PM
| > Subject: Re: Example use case.
| >
| >
| > | Paul Bolger wrote:
| > | > Ross
| > | >
| > | > This relates to an issue I've been thinking about for a while. If
one
| > | > had a pile of html and wanted to convert the docs to Forrest
internal
| > | > format, and then convert them back into html as a Forrest generated
| > | > site presumably leaving the source documents in their original
| > | > location would result in Forrest reconverting them whenever one of
| > | > them was requested - which would slow things down quite a lot. As
you
| > | > would only really want this done once what would be the best way to
| > | > approach a 'once-off' conversion' - run forrest once in 'build'
mode,
| > | > delete (or whatever) the original docs and then run Forrest in 'run'
| > | > mode?
| >
| > This is what I had in mind, rather than Incubator style using html docs
I
| > wanted to convert my existing into forrest source xml.
| > Thanks for putting it a better way!
|
| Yeah, David described how.
|
| >
| > |
| > | I would do it as a once-off conversion.
| > |
| > | If you are using old "skins" then set disable-xml-link=false
| > | in forrest.properties file. If using Dispatcher then
| > | this is enabled by default in this development phase.
| > |
| > | Do 'forrest site' to generate everything.
| >
| > This is more difficult for me I think. I have an index.php page
| > and a few others, the rest are .shtml pages.
|
| Ok, *if* you use the dispatcher you can actually "imitate" your site
| with structurer definitions (it is possible as well with "normal"
| forrest). So you need to "redirect" all calls for a *.xml in your xdocs
| to e.g. your webpage. The best for that is the locationmap.
| http://forrest.apache.org/docs_0_80/locationmap.html
|
| Now follow
|
http://forrest.apache.org/docs_0_80/locationmap.html#source-from-remote-cms
I tried using first v2 and then v3, both use dispatcher by default (?).
Reading other mails in this thread I didnt see a need to use the
locationmap as it hadn't been mentioned until now, but if that's
what you think it needs I will try it.
|
|
| > All of them 'include'
| > the main navigation which is in a separate nav.inc file.
| >
|
| I must see this file before saying anything but I reckon this is
semi-static, right?
It is just static html code. using either apaches 'include' or PHPs
'require_once'
they just retrieve the html content as is and put it in place of the include
statement
as request time. For me to keep this 'change one file, affects the whole
site' scenario
I am guessing then I may need to put this files contents into tabs.xml (but
see below)
A snippet of this code :-
<div id="navBar">
<div id="sectionLinks">
<h3>Navigation</h3>
<ul>
<li><a href="/forums/index.php">Visit the Forums</a></li>
<li><a href="/webdesign/webdindex.shtml">Web Design</a></li>
<li><a href="/apps/mtbrowser/index.shtml">- MTBrowser</a></li>
...
</ul>
</div><br />
<div id="leftbar">
<div class="leftsub">
<h5>IT Gazette Newsletter</h5>
</div>
</div>
</div>
|
| >
| > Forrest
| > is not therefore finding the navigation and not linking the site
| > properly.
| >
|
| That depends, you could write a custom transformation from your linking
file to site.xml,
| then you have forrest default behaviour.
Is there a howTo anywhere for this, an example?
That 'sounds' easier and better than adding my nav to tabs.xml.
|
| >
| >
| > There was mention that forrest can parse PHP, did I get this
| > wrong? Also I guess it wont parse the .shtml files either.
| >
|
| That is raw data, _normally_ this stuff just got let through.
Ok, and I guess Jetty wont parse it anyway. I would have
to upload a static site to test it.
|
| >
| >
| > Doing a forrest site does not produce any .xml files.
|
| Hmm, do you have the xml-link contract?
Tested using v2 and v3, this is enabled by default
in both isn't it?
|
| >
| > So this is the stage where I am at. I am thinking I should
| > remove any PHP requirements for now and rename them
| > to html extension. Then add back in to each page to each
| > page (using f & r) the navigation -- or should I be putting
| > my site navigation into the tabs.xml file -- or is there
| > another way to inlcude the nav.inc file.
|
| If you really consider to use pure forrest you *have to* have
| some kind (static/dynamic) of tab.xml/site.xml. I recommend
| to directly use tab/site.xml.
Ok, thanks Thorsten.
Gav...
|
| salu2
|
| >
| > Thanks
| >
| > Gav...
| >
| > |
| > | Perhaps you want to temporarily change forrest.properties
| > | to set a different location for project.site-dir
| > |
| > | That will generate the set of xml documents.
| > | They will be in document-v1.3 format rather than
| > | document-v2.0 because the former is still Forrest's
| > | internal format.
| > |
| > | Now copy those new sources from build/site/ into your
| > | src/documentation/xdocs/ space and remove the *.html
| > | versions. That will cause forrest to find the *.xml
| > | (i think that it searches for a .html source first
| > | then looks for a .xml source).
| > |
| > | That is basically how i did it for the Incubator
| > | site conversion, except i wrote a new output plugin
| > | to get the special output format.
| > |
| > | -David
| > |
| > |
| > | --
| > | No virus found in this incoming message.
| > | Checked by AVG Free Edition.
| > | Version: 7.1.375 / Virus Database: 267.14.20/234 - Release Date:
| > 18/01/2006
| > |
| > |
| >
| >
| >
| --
| thorsten
|
| "Together we stand, divided we fall!"
| Hey you (Pink Floyd)
|
|
|
| --
| No virus found in this incoming message.
| Checked by AVG Free Edition.
| Version: 7.1.375 / Virus Database: 267.14.20/234 - Release Date:
18/01/2006
|
|
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.20/234 - Release Date: 18/01/2006
Re: Example use case.
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 19-01-2006 a las 19:28 +0800, Gav.... escribió:
> ----- Original Message -----
> From: "David Crossley" <cr...@apache.org>
> To: <de...@forrest.apache.org>
> Sent: Thursday, January 19, 2006 12:39 PM
> Subject: Re: Example use case.
>
>
> | Paul Bolger wrote:
> | > Ross
> | >
> | > This relates to an issue I've been thinking about for a while. If one
> | > had a pile of html and wanted to convert the docs to Forrest internal
> | > format, and then convert them back into html as a Forrest generated
> | > site presumably leaving the source documents in their original
> | > location would result in Forrest reconverting them whenever one of
> | > them was requested - which would slow things down quite a lot. As you
> | > would only really want this done once what would be the best way to
> | > approach a 'once-off' conversion' - run forrest once in 'build' mode,
> | > delete (or whatever) the original docs and then run Forrest in 'run'
> | > mode?
>
> This is what I had in mind, rather than Incubator style using html docs I
> wanted to convert my existing into forrest source xml.
> Thanks for putting it a better way!
Yeah, David described how.
>
> |
> | I would do it as a once-off conversion.
> |
> | If you are using old "skins" then set disable-xml-link=false
> | in forrest.properties file. If using Dispatcher then
> | this is enabled by default in this development phase.
> |
> | Do 'forrest site' to generate everything.
>
> This is more difficult for me I think. I have an index.php page
> and a few others, the rest are .shtml pages.
Ok, *if* you use the dispatcher you can actually "imitate" your site
with structurer definitions (it is possible as well with "normal"
forrest). So you need to "redirect" all calls for a *.xml in your xdocs
to e.g. your webpage. The best for that is the locationmap.
http://forrest.apache.org/docs_0_80/locationmap.html
Now follow
http://forrest.apache.org/docs_0_80/locationmap.html#source-from-remote-cms
> All of them 'include'
> the main navigation which is in a separate nav.inc file.
>
I must see this file before saying anything but I reckon this is semi-static, right?
>
> Forrest
> is not therefore finding the navigation and not linking the site
> properly.
>
That depends, you could write a custom transformation from your linking file to site.xml,
then you have forrest default behaviour.
>
>
> There was mention that forrest can parse PHP, did I get this
> wrong? Also I guess it wont parse the .shtml files either.
>
That is raw data, _normally_ this stuff just got let through.
>
>
> Doing a forrest site does not produce any .xml files.
Hmm, do you have the xml-link contract?
>
> So this is the stage where I am at. I am thinking I should
> remove any PHP requirements for now and rename them
> to html extension. Then add back in to each page to each
> page (using f & r) the navigation -- or should I be putting
> my site navigation into the tabs.xml file -- or is there
> another way to inlcude the nav.inc file.
If you really consider to use pure forrest you *have to* have
some kind (static/dynamic) of tab.xml/site.xml. I recommend
to directly use tab/site.xml.
salu2
>
> Thanks
>
> Gav...
>
> |
> | Perhaps you want to temporarily change forrest.properties
> | to set a different location for project.site-dir
> |
> | That will generate the set of xml documents.
> | They will be in document-v1.3 format rather than
> | document-v2.0 because the former is still Forrest's
> | internal format.
> |
> | Now copy those new sources from build/site/ into your
> | src/documentation/xdocs/ space and remove the *.html
> | versions. That will cause forrest to find the *.xml
> | (i think that it searches for a .html source first
> | then looks for a .xml source).
> |
> | That is basically how i did it for the Incubator
> | site conversion, except i wrote a new output plugin
> | to get the special output format.
> |
> | -David
> |
> |
> | --
> | No virus found in this incoming message.
> | Checked by AVG Free Edition.
> | Version: 7.1.375 / Virus Database: 267.14.20/234 - Release Date:
> 18/01/2006
> |
> |
>
>
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Example use case.
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "David Crossley" <cr...@apache.org>
To: <de...@forrest.apache.org>
Sent: Thursday, January 19, 2006 12:39 PM
Subject: Re: Example use case.
| Paul Bolger wrote:
| > Ross
| >
| > This relates to an issue I've been thinking about for a while. If one
| > had a pile of html and wanted to convert the docs to Forrest internal
| > format, and then convert them back into html as a Forrest generated
| > site presumably leaving the source documents in their original
| > location would result in Forrest reconverting them whenever one of
| > them was requested - which would slow things down quite a lot. As you
| > would only really want this done once what would be the best way to
| > approach a 'once-off' conversion' - run forrest once in 'build' mode,
| > delete (or whatever) the original docs and then run Forrest in 'run'
| > mode?
This is what I had in mind, rather than Incubator style using html docs I
wanted to convert my existing into forrest source xml.
Thanks for putting it a better way!
|
| I would do it as a once-off conversion.
|
| If you are using old "skins" then set disable-xml-link=false
| in forrest.properties file. If using Dispatcher then
| this is enabled by default in this development phase.
|
| Do 'forrest site' to generate everything.
This is more difficult for me I think. I have an index.php page
and a few others, the rest are .shtml pages. All of them 'include'
the main navigation which is in a separate nav.inc file. Forrest
is not therefore finding the navigation and not linking the site
properly.
There was mention that forrest can parse PHP, did I get this
wrong? Also I guess it wont parse the .shtml files either.
Doing a forrest site does not produce any .xml files.
So this is the stage where I am at. I am thinking I should
remove any PHP requirements for now and rename them
to html extension. Then add back in to each page to each
page (using f & r) the navigation -- or should I be putting
my site navigation into the tabs.xml file -- or is there
another way to inlcude the nav.inc file.
Thanks
Gav...
|
| Perhaps you want to temporarily change forrest.properties
| to set a different location for project.site-dir
|
| That will generate the set of xml documents.
| They will be in document-v1.3 format rather than
| document-v2.0 because the former is still Forrest's
| internal format.
|
| Now copy those new sources from build/site/ into your
| src/documentation/xdocs/ space and remove the *.html
| versions. That will cause forrest to find the *.xml
| (i think that it searches for a .html source first
| then looks for a .xml source).
|
| That is basically how i did it for the Incubator
| site conversion, except i wrote a new output plugin
| to get the special output format.
|
| -David
|
|
| --
| No virus found in this incoming message.
| Checked by AVG Free Edition.
| Version: 7.1.375 / Virus Database: 267.14.20/234 - Release Date:
18/01/2006
|
|
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.20/234 - Release Date: 18/01/2006
Re: Example use case.
Posted by David Crossley <cr...@apache.org>.
Paul Bolger wrote:
> Ross
>
> This relates to an issue I've been thinking about for a while. If one
> had a pile of html and wanted to convert the docs to Forrest internal
> format, and then convert them back into html as a Forrest generated
> site presumably leaving the source documents in their original
> location would result in Forrest reconverting them whenever one of
> them was requested - which would slow things down quite a lot. As you
> would only really want this done once what would be the best way to
> approach a 'once-off' conversion' - run forrest once in 'build' mode,
> delete (or whatever) the original docs and then run Forrest in 'run'
> mode?
I would do it as a once-off conversion.
If you are using old "skins" then set disable-xml-link=false
in forrest.properties file. If using Dispatcher then
this is enabled by default in this development phase.
Do 'forrest site' to generate everything.
Perhaps you want to temporarily change forrest.properties
to set a different location for project.site-dir
That will generate the set of xml documents.
They will be in document-v1.3 format rather than
document-v2.0 because the former is still Forrest's
internal format.
Now copy those new sources from build/site/ into your
src/documentation/xdocs/ space and remove the *.html
versions. That will cause forrest to find the *.xml
(i think that it searches for a .html source first
then looks for a .xml source).
That is basically how i did it for the Incubator
site conversion, except i wrote a new output plugin
to get the special output format.
-David
Re: Example use case.
Posted by Paul Bolger <pb...@gmail.com>.
Ross
This relates to an issue I've been thinking about for a while. If one
had a pile of html and wanted to convert the docs to Forrest internal
format, and then convert them back into html as a Forrest generated
site presumably leaving the source documents in their original
location would result in Forrest reconverting them whenever one of
them was requested - which would slow things down quite a lot. As you
would only really want this done once what would be the best way to
approach a 'once-off' conversion' - run forrest once in 'build' mode,
delete (or whatever) the original docs and then run Forrest in 'run'
mode?
On 19/01/06, Ross Gardler <rg...@apache.org> wrote:
> Gav.... wrote:
> > Ok, so I have a site I have been throwing stuff into now and then, the
> > forums seem to be getting more popular, as are the stats steadily
> > rising. So I'd like to use forrest on it now.
> >
> > The site in question is http://www.minitutorials.com .
>
> ...
>
> > To the point, how do I now convert this site to use Forrest , v3 if possible
> > but
> > earlier if it illustrates it better to me.
>
> First thing to do is decide what you mean by "convert this site to use
> Forrest". In your questions below you indicate many options. I'll give
> you my own opinion and hopefully this will help you decide on exactly
> what you mean.
>
> > David C prompted me into this inadvertantly with his HTML conversions of
> > Incubator to Anakia. Do I have to manually re-write all of my sites .html or
> > .php pages into xml source files or can I do this another way.
>
> Forrest is about integrating multiple input types. No, you do not need
> to convert your existing content. David is doing the reverse for the
> Incubator. They have html and want to use Anakia, thus he is helping
> them convert from html to the necessary format by using Forrest.
>
> Forrest is already building the incubator site with the existing html
> sources, no conversion is necessary.
>
> > Ah, theres
> > something, most of my pages are PHP, does that make a difference. If it
> > does, I'll get rid of them I dont care, theres not much PHP code that I cant
> > do another way (or get rid).
>
> It really depends on what your PHP is doing. You mention (below) that
> one use is the inclusion of the navigation on the left and the panels on
> the right. This kind of inclusion need not be done in PHP, this would be
> done by the dispatcher.
>
> However, if you have some content that is being generated by PHP then
> you may choose to keep that PHP code and embed the output within your
> Forrest skinned page.
>
> There is no one answer to this, you need to evaluate each case in
> isolation. Forrest can support either keeping it or replacing it.
>
> > Then, looking at the site, can I then use CSS or whatever to somewhere near
> > resemble what I have currently or not - again, I don't care, its a useful
> > site, but
> > hardly earth-shattering and could probably do with a makeover anyway - which
> > when forrest-enabled I could do as often as I like with new themes right?
>
> Not a problem. Your site is pretty close to the default theme in the
> dispatcher. All that is required is to either modify the theme so that
> it uses the CSS lass names you define in your existing CSS or, use your
> existing CSS definitions with the current theme class names. The latter
> is probably easier.
>
> For an example look at the coat theme. This is really the default theme
> with a few contracts removed and a modified CSS file. It does not define
> any new contracts.
>
> ---
>
> How to proceed?
>
> I would forget about content in the first instance. Focus on getting
> your theme to look right. Once that is done you can start migrating
> content across.
>
> Do "forrest seed-v22 and modify the *.fv file and the CSS. See the
> recent thread David started regarding a "quick start" for dispatcher.
>
> Ross
>
Re: Example use case.
Posted by Ross Gardler <rg...@apache.org>.
Gav.... wrote:
> Ok, so I have a site I have been throwing stuff into now and then, the
> forums seem to be getting more popular, as are the stats steadily
> rising. So I'd like to use forrest on it now.
>
> The site in question is http://www.minitutorials.com .
...
> To the point, how do I now convert this site to use Forrest , v3 if possible
> but
> earlier if it illustrates it better to me.
First thing to do is decide what you mean by "convert this site to use
Forrest". In your questions below you indicate many options. I'll give
you my own opinion and hopefully this will help you decide on exactly
what you mean.
> David C prompted me into this inadvertantly with his HTML conversions of
> Incubator to Anakia. Do I have to manually re-write all of my sites .html or
> .php pages into xml source files or can I do this another way.
Forrest is about integrating multiple input types. No, you do not need
to convert your existing content. David is doing the reverse for the
Incubator. They have html and want to use Anakia, thus he is helping
them convert from html to the necessary format by using Forrest.
Forrest is already building the incubator site with the existing html
sources, no conversion is necessary.
> Ah, theres
> something, most of my pages are PHP, does that make a difference. If it
> does, I'll get rid of them I dont care, theres not much PHP code that I cant
> do another way (or get rid).
It really depends on what your PHP is doing. You mention (below) that
one use is the inclusion of the navigation on the left and the panels on
the right. This kind of inclusion need not be done in PHP, this would be
done by the dispatcher.
However, if you have some content that is being generated by PHP then
you may choose to keep that PHP code and embed the output within your
Forrest skinned page.
There is no one answer to this, you need to evaluate each case in
isolation. Forrest can support either keeping it or replacing it.
> Then, looking at the site, can I then use CSS or whatever to somewhere near
> resemble what I have currently or not - again, I don't care, its a useful
> site, but
> hardly earth-shattering and could probably do with a makeover anyway - which
> when forrest-enabled I could do as often as I like with new themes right?
Not a problem. Your site is pretty close to the default theme in the
dispatcher. All that is required is to either modify the theme so that
it uses the CSS lass names you define in your existing CSS or, use your
existing CSS definitions with the current theme class names. The latter
is probably easier.
For an example look at the coat theme. This is really the default theme
with a few contracts removed and a modified CSS file. It does not define
any new contracts.
---
How to proceed?
I would forget about content in the first instance. Focus on getting
your theme to look right. Once that is done you can start migrating
content across.
Do "forrest seed-v22 and modify the *.fv file and the CSS. See the
recent thread David started regarding a "quick start" for dispatcher.
Ross