On 10/28/2009 11:31 PM, Marius Dumitru Florea
wrote:
Teofil Achirei wrote:
Hi!
I was wondering if it's OK to add a third possible value for
stylesheet extension "use" property, something like "always on this
page". This could also be the default value.
As far as I know, the two possible values for SSX "use" property are:
- "on demand" - which means that any page can demand that SSX
- "always" - which means that all pages will have the CSS for that object
While these two properties are very good and practical, there are some
minor aspects:
1) Somebody (perhaps a designer) can create a SSX and other users
(perhaps content editors) forget to "demand" it
2) Having a SSX with use="always" and a second SSX with use="on
demand" both on the same page makes the two objects available for all
wiki pages (in term of client side CSS)
3) The content is aware of the design. It's ok if in the content of a
wiki page we can demand the stylesheet of another page, and that we
can create some stylesheet that will be used by all wiki pages. But,
in my opinion, the content must not be aware of it's own design.
This third value ("use"="always on this page") will also help other
projects like XOffice and XOO.
At this moment, XWord, for example, should follow these steps:
- save the page first (you can't create a SSX on an
unpublished/nonexistent page)
- identify saved page syntax (XWord works with XHTML)
- "know" how the SSX macro looks-like in page's syntax (yeah, not a
big deal, but it's something that XWord shouldn't care about)
- edit the content to insert the $xwiki.ssx.use($docFullname)
- publish the page, again
"Always on this page" (or "always on parent page") usage could
improve
some of the aspects mentioned above. Any other solution is welcomed.
What do you think?
I also think "always on this page" it's a nice option to have.
Another
solution I see is to be able to add a "SSX Use" object to a page to
enable a specific style sheet on that page without touching the page
content and without knowing velocity or other server-side scripting
languages.
+1 for the original idea, and +1 for this second idea, although it needs
refinement: how to specify the different types of extensions (jsx, jsfx
jsrx, and their ss equivalents)? One class per type, or a single class
with a "type" fields?
+1 too for both ideas
Personally I'd go for a single class with type (CSS/JS/link) and source
(wiki doc, filesystem, resource, etc) fields