A Complete List of PHP Template Engines?

[HarryF]

Well not entirely - we had an example of how an ASP.NET Calendar and how it might "bind" to an underlying PHP class here while looking at Parsing ASP.NET templates with PHP.

Looking at that example, the "template" was;

<asp:Calendar 
    id="cal" 
    SelectionMode="DayWeekMonth" 
    ShowGridLines="true" 
    ShowNextprevMonth="true" 
    CellPadding="7" 
    CellSpacing="5" 
    DayNameFormat="FirstTwoLetters" 
    FirstDayOfWeek="Monday" 
    NextPrevFormat="CustomText" 
    NextMonthText="Next 
    &gt;" 
    PrevMonthText="&lt; 
    Prev" 
    onSelectionChanged="SelectionChanged" 
    onDayRender="DayRender" 
    onVisibleMonthChanged="VisibleMonthChanged" 
    DayHeaderStyle-BackColor="Black" 
    DayHeaderStyle-ForeColor="White" 
    DayHeaderStyle-Font-Name="Arial 
    Black" 
    runat="server"> 
 
    <DayStyle 
    BackColor="White" 
    ForeColor="Black" 
    Font-Name="Arial" 
    /> 
 
    <NextPrevStyle 
    BackColor="DarkGray" 
    ForeColor="Yellow" 
    Font-Name="Arial" 
    /> 
 
    <OtherMonthDayStyle 
    BackColor="LightGray" 
    ForeColor="White" 
    Font-Name="Arial" 
    /> 
 
    <SelectedDayStyle 
    BackColor="CornSilk" 
    ForeColor="Blue" 
    Font-Name="Arial" 
    Font-Bold="true" 
    Font-Italic="true" 
    /> 
 
    <SelectorStyle 
    BackColor="CornSilk" 
    ForeColor="Red" 
    Font-Name="Arial" 
    /> 
</asp:Calendar>

Now that's fairly verbose but there's still no need to get bogged down in HTML tables - as you can see it's fairly "readable" - from the tag and attribute names it should be fairly clear how it effects the output. That's all a designer needs to do to customize the appearance of a "calendar widget" (plus they'd be using webmatrix or Visual Studio so be able to drag and drop anyway).

There's a tutorial on O'Rielly about creating custom ASP.NET controls which might give a feel for how it works.

[tezza]

Actually, I think the main attraction to leveraging the XSLT standard for your templating system is if you work in a team. As the backend PHP developer, you can easily implement something like XML Application Objects (in framework mode) to aggregate content and your own objects to process imput (XAO may eventually get a form input parser object). Then your gumby graphic designers can use a tool like stylevision ( http://www.altova.com/products_xsl.html ), if they are not already XHTML markup savvy, to design the stylsheets. All you have to do is point to the stylsheets.

If you're really clever, you'll have one stylsheet (the controller for your presentation logic) which calls/applies templates from other IMPORTed template definitions. But you don't have to do this if you feel it is too complicated. You have the choice to KISS.

Now *this* is how you build enterprise applications - using standards.

BTW. You can use the same library (XAO) to aggregate content from a variety of sources (as illustrated in my actual code examples which everyone seems to have no comment on) - including DBMS (using the DB2XML class), RSS, XML-RPC (SOAP), Xindice (pure XML databse), and good 'ol flat files (includung Open Office documents). What more do you want???

And then one day when you have to migrate all your stuff to Java or .NET (because it's trendy), you can keep all those XSL files and re-use them (and possible do an object-for-object code port for the backend). Or better yet, use an XSLT file to export SOAP packets so they can access your PHP app via XML-RPC rather than port the whole app across. In this case, the XSLT will save you from having to write more code to produce payload for a different kind of client (which is the remote app). How good is that???

Dr Livingston is right - "we *need* this people".

[tezza]

Well not entirely - we had an example of how an ASP.NET Calendar and how it might "bind" to an underlying PHP class here while looking at Parsing ASP.NET templates with PHP.

Looking at that example, the "template" was;

<asp:Calendar 
    id="cal" 
    SelectionMode="DayWeekMonth" 
    ShowGridLines="true" 
    ShowNextprevMonth="true" 
    CellPadding="7" 
    CellSpacing="5" 
    DayNameFormat="FirstTwoLetters" 
    FirstDayOfWeek="Monday" 
    NextPrevFormat="CustomText" 
    NextMonthText="Next 
    &gt;" 
    PrevMonthText="&lt; 
    Prev" 
    onSelectionChanged="SelectionChanged" 
    onDayRender="DayRender" 
    onVisibleMonthChanged="VisibleMonthChanged" 
    DayHeaderStyle-BackColor="Black" 
    DayHeaderStyle-ForeColor="White" 
    DayHeaderStyle-Font-Name="Arial 
    Black" 
    runat="server"> 
 
    <DayStyle 
    BackColor="White" 
    ForeColor="Black" 
    Font-Name="Arial" 
    /> 
 
    <NextPrevStyle 
    BackColor="DarkGray" 
    ForeColor="Yellow" 
    Font-Name="Arial" 
    /> 
 
    <OtherMonthDayStyle 
    BackColor="LightGray" 
    ForeColor="White" 
    Font-Name="Arial" 
    /> 
 
    <SelectedDayStyle 
    BackColor="CornSilk" 
    ForeColor="Blue" 
    Font-Name="Arial" 
    Font-Bold="true" 
    Font-Italic="true" 
    /> 
 
    <SelectorStyle 
    BackColor="CornSilk" 
    ForeColor="Red" 
    Font-Name="Arial" 
    /> 
</asp:Calendar>

Now that's fairly verbose but there's still no need to get bogged down in HTML tables - as you can see it's fairly "readable" - from the tag and attribute names it should be fairly clear how it effects the output. That's all a designer needs to do to customize the appearance of a "calendar widget" (plus they'd be using webmatrix or Visual Studio so be able to drag and drop anyway).

There's a tutorial on O'Rielly about creating custom ASP.NET controls which might give a feel for how it works.

OK, I see how this works.

What is hidden [from this post] is the details for how your .NET library (or your PHP alternative) will build the layout.

You are claiming that I don't have to stuff around with tables and what not. Well this may be true but someone has built this in a library on the backend somwhere - this is a backend widget designed by a programmer.

What's to stop an XSLT person from utilising a library which included a calendar template? Then they woudln't have to stuff around with tables either. All they would have to do is call it using <lalala:call-template name="myCalendarWidgetV3"/>

Now, wouldn't it be nicer if mr designer had access to the source of the widget if they needed to tweak it? Also, they would then see that the widget used class attributes in the XHTML literals so the developer could quickly make a CSS file which is how the styles *should* be applied.

Now when the designer calls the template, the only parameters they will need to pass are logical ones like which day/week/month to display as current. The *APPEARANCE* attributes (as opposed to the display semantics) can be left to the CSS file - which I do believe is another standard (that XSLT does not impinge on).

<l:call-template name="myCalendarWidgetV3">
    <l:param name="scope" select="'month'"/>
    <l:param name="current" select="'august'"/>
</l:call-template> 

now the colours and font sizes are dependent on the rendering platform. In this case, the rendering platform is HTML based. So for HTML, the correct way to specify these details is CSS.

[Selkirk]

How come everyone is ignoring the fact that there are already many content editors (such as XMetal) that allow you to edit your content as WYSIWYG with your standards based XSLT template applied.

The DreamWeaver test applies to editing the templates in a WYSIYWG editor, not the content.

Well how about developing new templates? How many of you can claim that even one software package out there helps users develop templates in your syntax - ie. generate your proprietary format?

Well, I've used the "Edit Tag Library..." command of DreamWeaver to enter the custom tags and attributes from WACT (via a GUI). Now when I edit WACT templates in DW, it can autocomplete closing tags and attribute values for the custom tags. I also entered formatting rules for the custom tags so the "Apply Source Formatting" command understands the new tags. My new tags appear in DW's 'Insert Tag..." command. I can also highlight my custom tags from the little tag breadcrumbs widget at the bottom of the editing window.

ASP.NET and Java Server Pages both allow you to create custom tags. I expect that editor support for custom tags will only improve in the future.

A little googling turned up a dreamweaver custom tag library for Xaraya.

[tezza]

Well, I've used the "Edit Tag Library..." command of DreamWeaver to enter the custom tags and attributes from WACT (via a GUI). Now when I edit WACT templates in DW, it can autocomplete closing tags and attribute values for the custom tags. I also entered formatting rules for the custom tags so the "Apply Source Formatting" command understands the new tags. My new tags appear in DW's 'Insert Tag..." command. I can also highlight my custom tags from the little tag breadcrumbs widget at the bottom of the editing window.

Well DW "understands" your new tags to a point but it's not going to have your template engine built into the editor so that it can fully translate tags such as the <calendar/> example. The other content authoring tools (like XMetal and Authentic) actually do have an XSLT processor built into them so they can translate the WYSIWYG in real-time while you edit. What you are talking about is not the same thing.

also, in terms of getting DW to insert custom tags, I can do that with a non-gui text editor too like Homesite. Just because DW can insert those tags doesn't mean it can translate it to look how it will end up on the finished rendered page - otherwise what is a WYSIWYG editor like DW good for?

Stylevision on the other hand *can* do exactly this. It can generate XSLT and it can also WYSIWYG it in real-time.

ASP.NET and Java Server Pages both allow you to create custom tags. I expect that editor support for custom tags will only improve in the future.

bully for them. Using custom tags for display widgets just means you lose your decoupling between the domains (display and content generation). Using custom tags to encapsulate server-side business functionality is a different thing, and in that case, it's not even applicable as layout/design templates.

Here's an example of where a custom tag *would* be useful. You make a custom tag, say <faqItem id="foo"/> which fetches the content of an FAQ record in the database. Now to avoid having this tangled up in the database, your templating engine does NOT render this as some pre-set, inflexible, encased, hard-coded, dead-end HTML. Your template parser produces something like the following instead:

<faqItem id="foo">
    <faq>Why are there so many template languages for PHP?</faq>
    <answer>Sadly, many PHP developers haven't taken the time to understand XML.</answer>
</faqItem> 

*then* you use arbitary (NOT(pre-set, inflexible, encased, hard-coded, dead-end)) XSLT to produce whatever the hell output THE DESIGNER wants.

Now you might say doing this just adds another layer. Well, you'd be right. Which is why I tend to get all the conent I need in one hit (without parsing some external file for custom tags) and then sending it through the transformer (format router) consumption by the client. But hey, if you chose to use custom tags, that's cool, choice is good. But try not to let them muck up your abstraction layers by confusing them with display logic. Using them for content expansion is fine, but they are not a solution for display logic abstraction.

[prefab]

namespaces in XML were designed to provide the sort of scope management you are trying to achieve. If you do it the standards way, there will likely be more opportunities to enhance the technology.

You're right! The problem is that HTMLSax doesn't support namespaces (yet), maybe HarryF got that planned though?

I'll look into it though, maybe I'll stay with the original SAX, which support namespaces. Maybe someone has an example of how to parse with namespaces in PHP?

- prefab

[tezza]

Make sure you use
http://au2.php.net/xml_parser_create_ns
and not
http://au2.php.net/xml_parser_create

to create your parser.

I'm assuming your element handler will then get "ff:customtag" in the second param (the $name).

$arrQualified = explode(":",$name);
if(count($arrQualified) == 2) {
    if($arrQualified[0] == "ff") // do you thang baby.
} 

This is still a hack, because now you are relying on them to have "ff" to QUALIFY their elements. THis is BS though because an element name prefix is neccesarily bound to a declaration. It is the declaration that is unique and it is the declaration that should be specifid as part of your template specification. so maybe in the outer container of your template you have

yadda yadda yadda....
<container scope="not necessarily the root element" xmlns:ff="prefab.org/specs/schema/customtemplates">
<ff:lalalala>foo bar choo</ff:lalalala>
</container>
more crap goes here if you like... 

then you should use http://au2.php.net/xml-set-start-namespace-decl-handler

to test for "prefab.org/specs/schema/customtemplates" and then find out what prefix the user bound to it.

ie. they might have done

yadda yadda yadda....
<container scope="not necessarily the root element" xmlns:fooloo="prefab.org/specs/schema/customtemplates">
<fooloo:lalalala>foo bar choo</fooloo:lalalala>
</container>
more crap goes here if you like... 

so now your processor is obligated to parse the fooloo prefix.

It's worth doing properly. trust me.

Namespaces make the concept of XML work. If it weren't for namespaces, XML would be ignorable. Namespaces were designed precicely to handle situations like yours.

You do realise that you are re-inventing JSP/ASP.NET

<jsp:useBean id="calendar" scope="application" class="org.whatever" /> 

PS.
The namespace declaration string doesn't have to mean anything, but it is intended to be a world-wide primary key (globally unique) so people use their domain names (plus a path) by convention.

[tezza]

If you want a sneak peek at the source for XML Application Objects you can pull it from the CVS

cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/xao-php co prodigy

I will create a downloadable file when it reaches alpha.
please keep correspondance about XAO issues to the mailing list at
https://sourceforge.net/mail/?group_id=88235

lota lota work to do :/
even though 90% of it works

[Selkirk]

Ok, I took a look at the Altnova Stylesheet designer. Now some of what you were saying tezza makes more sense.

• Load the Schema that forms the basis of your HTML document
• Assign a working XML document which provides preview data
• Drag and drop the specific schema elements into Stylesheet Designer window
• Preview the results in Internet Explorer or Adobe Acrobat
• Save the Stylesheet Designer template (*.sps) as a basis for XML documents in Authentic
• Save the automatically generated XSLT or XSLT:FO output.

The XSLT Stylesheet is automatically created for you!

Its not a WYSIWYG editor for arbitrary XSLT. As I understand it, they constrain what you can do (hence the intermediate .sps format). They then translate that format in to XSLT. You cannot edit the XSLT output and read it back into the tool.

Interestingly enough, the little tan tags from this screen shot look very much like the data binding tags that you would see in any basic template. So you drag data bindings from the tree view on the left into your document. Dreamweaver has a data bindings palette where you can do the same thing. I haven't used it much. I'm gonna have to play with it.

I still don't think that an XSLT file is a template, but I am beginning to think that an .sps file might be one. I wonder what an .sps file looks like.

Have you used this product, tezza?

I am curious to find out if there are other products that take the same approach to generating XSLT documents, or if this one is unique.

[Karl]

Not read all this thread as I'm right in the middle of a shed load of work right now. But yes, I am using DOM XSL functions in a production environment, it works like a dream and is roughly 50% faster than doing the exact same job with Sablotron.

Although many hosts have DOM support compiled in, you must also check that theu have the XSL part compiled in as well, as the XSL part requires another configure directive and that libxsl be installed on the server too.

[tezza]

Its not a WYSIWYG editor for arbitrary XSLT.

Hmmm. Apologies for being mis-leading. I basically went on the information that was on their website (which I pasted as a quote a few posts ago) which led me to believe it was a WYSIWYG design tool for XSLT.
Content authoring is definately WYSIWYG though. It uses a "hard-wired" style sheet. This I have definately tried.

As I understand it, they constrain what you can do (hence the intermediate .sps format). They then translate that format in to XSLT. You cannot edit the XSLT output and read it back into the tool.

No round trip?
boooooh!

Interestingly enough, the little tan tags from this screen shot look very much like the data binding tags that you would see in any basic template. So you drag data bindings from the tree view on the left into your document. Dreamweaver has a data bindings palette where you can do the same thing. I haven't used it much. I'm gonna have to play with it.

Yeah, I think when macromedia aquired drumbeat, they tried to integrate databinding for scripting languages. I don't think that idea was ever gonna work. Either you know how to write ASP/ColdFusion or you don't. You're not gonna use some inherently limited GUI tool to do it.

I still don't think that an XSLT file is a template, but I am beginning to think that an .sps file might be one. I wonder what an .sps file looks like.

Well I won't assert that it is but I will assert that it achieves outcomes in the same domain, broadly speaking. I also haven't seen any template technology that scales as well complexity wise - and I'm not equating level of imperative functionality to level of sophistication.

Have you used this product, tezza?

No. I've been using Homesite (old habbit) and sometimes Eclipse (with the XMen plugin). I should probably switch to XML-Spy even for their XML centric text editor alone. I got a "personal edition" on the cover of a magazine
- better not use it for any commercial projects then...

As a developer I haven't needed a GUI design tool but since there was discussion about DW and such, I thought we were bringing "other" users into the question about what makes a good template technology.

The way I see it, you have 3 groups in the immediate scope of the templates issue.
1) Developer (backend business logic)
2) Site Designer (graphic designer with XHTML/XSL knowledge)
3) Content Author (data entry. eg. "Authentic" text editor)

I assume these are the groups that everyone else had in mind with their "tools for templates" discussion thread.

I am curious to find out if there are other products that take the same approach to generating XSLT documents, or if this one is unique.

Altova seem to be the leaders (no, I don't work for them). But I expect XSLT tools to become more prolific, especially with XSLT v2 on the horizon. XMetal is another old vetaran for XML content editing. Microsoft and Sun both push the whole XML and surrounding technologies pretty hard. I'd be surprised if VS.NET didn't have some sort of XSLT tool. (I haven't had time to check out VS)

[jasonlotito]

Maybe the Dreamweaver rule could probably be better defined as the WYSIWYG rule to avoid any confusion?

[tezza]

Not read all this thread as I'm right in the middle of a shed load of work right now. But yes, I am using DOM XSL functions in a production environment, it works like a dream and is roughly 50% faster than doing the exact same job with Sablotron.

Although many hosts have DOM support compiled in, you must also check that theu have the XSL part compiled in as well, as the XSL part requires another configure directive and that libxsl be installed on the server too.

I haven't had the same luck with all my XSLT templates. Maybe the XSLT processor you're using is differnt from mine. I've been testing
http://au.php.net/domxsltstylesheet-process
which is labelled as experimental. I've been testing it under windows with nothing but php_domxml.dll - this build could be different I suspect.

XAO allows the user to choose which transform processor they wish to use. By default, DomDoc::strXsltProcessor == "SABLOTRON"

SF.net does not have DOMXML or XSLT enabled :-(
(yet. I applied to have this changed in the future).


can you see if the followig XSL works for you?

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet 
    version="1.0" 
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    
    <xsl:output method="html" />

    <xsl:template match="//errors">
        <html>
            <head>
                <title>my AppDoc Error</title>
            </head>
            
            <body style="font-family: monospace;">
                <h1>Error</h1>
                <ul>
                    <xsl:apply-templates select="error" />
                </ul>
            </body>
        </html>
    </xsl:template>

    <xsl:template match="error">
        <li>
            <div style="font-weight: bold;"><xsl:value-of select="msg"/></div>
            <xsl:apply-templates select="stack" />
        </li>
    </xsl:template>
    

    <xsl:template match="stack">
        <div>stack trace</div>
        <xsl:apply-templates select="call" />
    </xsl:template>


    <xsl:template match="call">
        <ul>
            <li>call: <span style="color: red;"><xsl:value-of select="@class"/><xsl:value-of select="@type"/><xsl:value-of select="@function"/></span></li>
            <xsl:apply-templates select="args/item" />
            <li>loc: <xsl:value-of select="@file"/> (<xsl:value-of select="@line"/>)</li>
            <xsl:apply-templates select="call" />
        </ul>
    </xsl:template>
    
    <xsl:template match="args/item">
        <xsl:if test="text() != ''">
            <div style="margin-left:20px;">arg:<xsl:value-of select="text()"/></div>
        </xsl:if>
    </xsl:template>

</xsl:stylesheet>

The XAO exception handling subsystem produces the XML which this stylesheet is used on during debugging. It is generated from the array returned by http://au2.php.net/debug_backtrace

here is some example imput

<?xml version="1.0"?>
<?xml-stylesheet  type="text/xsl" href="errors.xsl"?>
<blogApp>
  <appTitle>XAO Tutorial 1a: The logger.</appTitle>
  <appInfo>This is a tutorial application for XAO.</appInfo>
  <error ts="1061389652">
    <msg>The stylsheet you specified: ______index.xsl does not exist. Set local file checking (parsing) to
                    false in the second argument of DomDoc::ndSetStylePI() if
                    the file exists remotely or you want to override checking.</msg>
    <stack>
      <call file="c:\www\xao\classes\DomDoc.php" line="716" function="throw" class="appdoc" type="-&gt;">

        <args>
          <item>The stylsheet you specified: ______index.xsl does not exist. Set local file checking (parsing) to
                    false in the second argument of DomDoc::ndSetStylePI() if
                    the file exists remotely or you want to override checking.</item>
        </args>
        <call file="c:\www\xao\tutorials\1a\class\AppDoc.php" line="15" function="ndsetstylepi" class="appdoc" type="-&gt;">
          <args>
            <item>______index.xsl</item>
            <item>[1]</item>

          </args>
          <call file="c:\www\xao\tutorials\1a\index.php" line="3" function="appdoc" class="appdoc" type="-&gt;"/>
        </call>
      </call>
    </stack>
  </error>
</blogApp>

the above XSLT works with all other XSLT processors including the ones built into Mozilla and IE.

[Dr Livingston]

Karl -

Just out of curiosity I suppose, I'd be interested in knowing more on how you've managed to get PHP4.x to use the DOM and XSL to transform an XML file ? Maybe post some script as well if we're lucky

As to my view on using DW MX and XML I'd really have to say that DW MX has little support either for XML or XSL-T which is seriously lacking at the moment.

IMO in this day and age and for the number of years that XML and XSL-T have been around I'd have thought that Macromedia by now would have implemented far more functionality into DW MX to support XML and it's related technologies.

[lieut_data]

Just a note to any newbie (like me) reading through this enlightening article -- I'd recommend pronouncing XSLT as "exalt", as recommended by http://sources.redhat.com/ml/xsl-lis.../msg00038.html

So far, this has helped me greatly in just reading these articles...

[tezza]

... i.e. XSLT vs the world

not having a go at alfred3x or anything but does anyone else see the irony here?

[Karl]

tezza - If the output is supposed to look like: http://www.karlaustin.com/test/spDomXSLTest.php then I would guess it's working

The php_domxml.dll doesn't come with the XSL support for DOM as far as I am aware, although I think there is a way of getting it for Windows, just not sure how off the top of my head.

[Hartmann]

Harry,

I have been keeping up with this thread and looking at all of the templating engines that have been mentioned. My question is, are they really needed? Is it more of a preference thing or a necessity?

I know I have been trying to write to an XML/RSS feed and using something pre-built is probably the best route but nothing I look at seems simple enough for me to put in my exsisting code...

[tezza]

I know I have been trying to write to an XML/RSS feed and using something pre-built is probably the best route but nothing I look at seems simple enough for me to put in my exsisting code...

At the moment, I don't believe integrating XSL into php pages is as simple as it could be. Some of us don't mind the overhead of writing some sort of framework to "manage" the whole process, but we're obviously in the minority. This I think is part of the reason that everyone is _still_ using proprietary templates in this day and age.

I'm hoping my XAO library (a pre-built option of which you speak) will change all that. Why not tell me what you want at my project forum at sf.net?
http://sourceforge.net/forum/forum.p...orum_id=302977

I've put a whole bunch of stuff under the tasks section. It will give you a good indication of my current intentions are and will act as a sort of roadmap for now.

while we're at it, I'll take this opportunity for a demo on how one might appropriate an RSS feed.

$objAppDoc = new AppDoc("RSS4MyApp.xsl");
$objRss = new RssFeed("http://cyber.law.harvard.edu/blogs/gems/tech/sampleRss20.xml");
$objAppDoc->ConsumeDoc($objRss->objDoc);
$objAppDoc->TransformSend("text/html"); // default header sends "application/xml" 

[tezza]

tezza - If the output is supposed to look like: http://www.karlaustin.com/test/spDomXSLTest.php then I would guess it's working

good enough for me

[drush]

So if I can beg a momemt of time, please add any template engines you know of to this list. They don't have to be stand alone projects - phpBB for example has it's own template engine so that counts as one. The main thing is identifying unique template engines.

TemplateTamer

It commes together with dev environment for templates, IDE, project, tree view of template structure, code generator. It features "clean" templates with no code inside them.

rush

[HarryF]

Hmmm - lost count - need to find the last count

Heres another: http://www.phptemple.de

From a quick glance looks interesting with perhaps a flavor of ASP.NET

[nok]

Well, just another template engine, Fastemplate like with a simple cache system. Nothing new, the only diference with the others is that this one is completly written in "Spanish" and of course by myself.

Noktemplate

[Dr Livingston]

Are you doing a translation to English ? Looked just now at some example scripts and I get the general idea though I have only one spoken language and that's the Scots version of the Queens English...

Once we were described as barbaric... We still are

[cagrET]

mgcLib
and
mgcLib :: Template

http://sourceforge.net/project/showf...ease_id=172516

huh