Re: [RT] Why using views - in comparison with "old fashion" skins - usecase i18n.

[Diwaker Gupta <di...@gmail.com>]

On 6/4/05, Thorsten Scherler <th...@apache.org> wrote:
> 
> I had to extend the default.fv with a new line:
> <forrest:contract name="last-published"/>
> to activate the new contract in any place of the output that I want. As
> well it is possible to place the contract as much as I want.
> 
> Refactoring site2xhtml.xsl has similarities of generating contracts for
> the view plugin. The biggest different is that we extract the code
> snippet in another file and not the site2xhtml.xsl and winning the
> flexibility of placing it where we want.
> 
> That prevent as well the situation where you have to "rip parts out of
> the skin" if you do not want them. In views you just do not use the
> contract and it will not be outputed.

Hi,

This looks great! On a related note, is anyone working on a "Credits" nugget?

A long time back I had complained about the use of Javascript for
generating the last published timestamp, and till date there is no
neat solution for doing this from within XSLT. Javascript is great (as
Google has aptly demonstrated), but for my static pages generated from
Forrest, I would like the timestamp to be visible even in text
browsers like elinks. Today as I was again browsing to find a
solution, I came across this:

http://www.dpawson.co.uk/xsl/sect4/dateTime.html#d12477e16

It seems to me like a reasonably good solution (atleast in the short
term). I have modified my local copy of the last-published contract to
use this. If there's interest, I can submit a patch.

Cheers,
Diwaker

-- 
Diwaker Gupta
http://resolute.ucsd.edu/diwaker

Re: [RT] Why using views - in comparison with "old fashion" skins - usecase i18n.

[Thorsten Scherler <th...@apache.org>]

On Sat, 2005-06-04 at 21:03 -0700, Diwaker Gupta wrote: 
> > Yes that would be great. :) That could be the 'last-published-net'
> > contract.
> 
> Its funny, I chose the *exact* same name even before I wrote my first mail :)
> 

lol :)

Yeah, once started working with views and contracts the naming for the
contracts is pretty straight forward I guess. :) ;-)

> Anyways, I'm attaching last-published-net.ft. It uses an improved
> version of the XSL date service (no Perl script!). 

:) very nice. I just copied the contract in my local development project
(for testing) and it works like a charm. :) Thx a million. 

I will check that now in (in the viewHelper.xhtml) with a small change
in the caption instead of 
Last published on <xsl:value-of select="$dt"/>

I will checkin
<i18n:text >Last Published:</i18n:text>&#160; <xsl:value-of
select="$dt"/>

Now were we set up the i18n support we should use it. ;-)

I added as well a blank.ft which can serve as copy'n paste master in the
beginning for your offline editor and later on for the cform-based
view/contract online-editor-plugin I will add (hopefully) soon. 

BTW if you want to submit another contract that will get rid of jscript,
try sending a patch for http://issues.apache.org/jira/browse/FOR-134
Right now that do not exists as a contract, but I would like to see the
breadcrumbs.ft solving FOR-134 and not implementing the old
code. ;-) ...after wards it easy to back port that to "old fashion
skins".

> In addition, if a
> network connection is not available, one can use a similar solution on
> the localhost -- I have written a simple Python script to generate the
> required XML, so just replace the URL in the document function call
> with the path to date.py
> 

:) For now I did not check that script in but if you could write some
words how to setup everything and provide a 'last-published-local-net'
contract I will do that ASAP. 

My problem is where to add the *.py. IMO that is a businessService and I
still have to still look into the locationmap branch where I guess
businessServices should be defined. 

BTW the commits and mails relating to that topic are *very* promising.
@Ross how are the changes that we can use the locationmap stuff in a
plugin (businessHelper-plugin). ;-)

> I had a related question: it seems wasteful to generate the timestamp
> again and again for each processed file. Since the build happens
> within a few minutes at most, I'm content with recording the time at
> the start of the build and then using that throughout. This will save
> a lot of CPU cycles. I'm not an expert at XSL so I'm still looking as
> to what is the best way to define such a "global timestamp variable".
> 

Yeah +1 

Any suggestions how to implement that? Maybe with the locationmap? 

Thank you very much, Diwaker, for your constant testing effort, feedback and patches for views that is helping me a million. Keep on! :)

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

Re: [RT] Why using views - in comparison with "old fashion" skins - usecase i18n.

[Diwaker Gupta <di...@gmail.com>]

> Yes that would be great. :) That could be the 'last-published-net'
> contract.

Its funny, I chose the *exact* same name even before I wrote my first mail :)

Anyways, I'm attaching last-published-net.ft. It uses an improved
version of the XSL date service (no Perl script!). In addition, if a
network connection is not available, one can use a similar solution on
the localhost -- I have written a simple Python script to generate the
required XML, so just replace the URL in the document function call
with the path to date.py

I had a related question: it seems wasteful to generate the timestamp
again and again for each processed file. Since the build happens
within a few minutes at most, I'm content with recording the time at
the start of the build and then using that throughout. This will save
a lot of CPU cycles. I'm not an expert at XSL so I'm still looking as
to what is the best way to define such a "global timestamp variable".

Diwaker
-- 
Diwaker Gupta
http://resolute.ucsd.edu/diwaker

Re: [RT] Why using views - in comparison with "old fashion" skins - usecase i18n.

[Thorsten Scherler <th...@apache.org>]

On Sat, 2005-06-04 at 19:04 -0700, Diwaker Gupta wrote:
> On 6/4/05, Thorsten Scherler <th...@apache.org> wrote:
> > 
> > I had to extend the default.fv with a new line:
> > <forrest:contract name="last-published"/>
> > to activate the new contract in any place of the output that I want.
As
> > well it is possible to place the contract as much as I want.
> > 
> > Refactoring site2xhtml.xsl has similarities of generating contracts
for
> > the view plugin. The biggest different is that we extract the code
> > snippet in another file and not the site2xhtml.xsl and winning the
> > flexibility of placing it where we want.
> > 
> > That prevent as well the situation where you have to "rip parts out
of
> > the skin" if you do not want them. In views you just do not use the
> > contract and it will not be outputed.
> 
> Hi,
> 
> This looks great! On a related note, is anyone working on a "Credits"
nugget?

You mean contract? No I added some today but mainly related to the
document (content-contract). If you want go ahead and add it. ;-)

In my testing fv I added for replacing the content-contract (which was
the direct parse through from document2html.xsl from leather):
<forrest:hook name="content">
  <forrest:contract name="fontsize"/>
  <forrest:contract name="content-title"/>
  <forrest:hook name="last-published-tagline">
    <forrest:contract name="last-published"/>
    <forrest:hook name="motd-page" >
     <forrest:contract name="motd-page"/>
    </forrest:hook>
   </forrest:hook>
   <forrest:contract name="minitoc"/>
   <forrest:contract name="content-abstract"/>
   <!--Fixme:<forrest:contract name="content-main"/>-->
</forrest:hook>

I will finish tomorrow the content-main hopefully. ;-)

> 
> A long time back I had complained about the use of Javascript for
> generating the last published timestamp, and till date there is no
> neat solution for doing this from within XSLT. Javascript is great (as
> Google has aptly demonstrated), but for my static pages generated from
> Forrest, I would like the timestamp to be visible even in text
> browsers like elinks. Today as I was again browsing to find a
> solution, I came across this:
> 
> http://www.dpawson.co.uk/xsl/sect4/dateTime.html#d12477e16
> 
> It seems to me like a reasonably good solution (atleast in the short
> term). I have modified my local copy of the last-published contract to
> use this. If there's interest, I can submit a patch.
> 

Yes that would be great. :) That could be the 'last-published-net'
contract. 

> Cheers,
> Diwaker
> 

salu2
> 
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)