[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