[Yanel-dev] Introduce an htdocs/xslt directory

Guillaume Déflache guillaume.deflache at wyona.com
Tue Sep 1 21:51:12 CEST 2009


Michael Wechner schrieb:
> Guillaume Déflache schrieb:
>> [...]
>> I think this so-called "packaging-by-feature" grouping should be a 
>> long-term goal of Yanel, as IMHO it helps maintainability a lot.
> 
> very good point, but AFAIK we only have grouping by technology yet  

Mostly yes, but I'd say it's (understandably) not
thoroughly/systematically applied, see
http://svn.wyona.com/repos/public/yanel/trunk/src/webapp/htdocs/ where
some .css/.png somehow are not in the yanel-css/yanel-img folders.


> (which I don't consider personally bad necessarily) and we don't

I found the two articles cited in my previous mail pretty convincing, do
you have any [pointers to] counter-arguments? I'd be genuinely
interested to hear of any drawbacks. No regex/glob-based
request-URI-filtering being available on some web servers (IIS...) was
one long ago for example.


> have any other plan.

I'd say we already had a evil/secret/master plan loosely based on
"grouping by technology", even if it's implicit!


> So I think either we come up with a plan that makes more sense, or else 
> we stick to grouping by technology,
> which is still better than no plan ;-)
> 
> Do you have any suggestions how we should group the files?

IMHO this "packaging-by-feature" stuff makes more sense, but it is
inevitably going to clash with the old (non-)organisation because of
backward-compatibility. I'd like us to follow this path however, I don't
think things will get much more inconsistent that they already are.


A real world and I think meaningful example:
http://svn.wyona.com/repos/public/yanel/trunk/src/webapp/htdocs/
IMHO it should rather *not* look like:

|-- help.html
|-- yanel-css
|   |-- global.css
|   |-- progressBar.css
|   |-- progressBarTerminated.css
|   |-- toolbar.css
|   |-- toolbarIE.css
|   |-- toolbarIE6.css
|   |-- toolbarMozilla.css
|   `-- view-access-policy.css
|-- yanel-htc
|   `-- csshover.htc
|-- yanel-img
|   |-- icons
|   |   |-- folder-new.png
|   |   |-- folder.png
|   |   |-- go-up.png
|   |   |-- system-log-out.png
|   |   `-- text-x-generic.png
|   |-- ssl_off.png
|   |-- ssl_on.png
|   |-- submenu.gif
|   |-- yanel_header.png
|   `-- yanel_toolbar_logo.png
|-- yanel-js
|   |-- progressBar.js
|   |-- prototype.js
|   `-- sorttable.js
|-- yanel-xsl
|   |-- identity-transformation.xsl
|   |-- html.xslt
|   |-- Google-Analytics.xslt
|   `-- page-Google-Analytics.xslt

Seeing no advantages here, and filenames have to be longer because they
lack context.


Instead it should probably look something like:

|-- Google-Analytics
|   |-- GA.xslt
|   `-- page-GA.xslt
|-- commons
|   |-- identity-transformation.xsl
|   |-- csshover.htc
|   |-- prototype.js
|   `-- sorttable.js
|-- help.html
|-- default-skin
|   |-- html.xslt
|   `-- global.css
|-- toolbar
|   |-- toolbar.css
|   |-- toolbarIE.css
|   |-- toolbarIE6.css
|   |-- toolbarMozilla.css
|   |-- yanel_header.png
|   |-- yanel_toolbar_logo.png
|   `-- submenu.gif
|-- progress-bar
|   |-- progressBar.css
|   |-- progressBarTerminated.css
|   `-- progressBar.js
|-- access-policy
|   `-- view-access-policy.css
|-- node-browser
|   |-- folder-new.png
|   |-- folder.png
|   |-- go-up.png
|   `-- text-x-generic.png
|-- security
|   |-- system-log-out.png
|   |-- ssl_off.png
|   `-- ssl_on.png

This helps to keep naming inside a given module consistent, and you can
compare modules side-by-side rather easily.


What you will see at the top-level in each case:
- yanel-css yanel-htc yanel-img yanel-js yanel-xsl
- [unsorted:] Google-Analytics commons default-skin toolbar progress-bar
access-policy node-browser security

Speaks for itself I guess! :)


More information about the Yanel-development mailing list