11 Dec
2014
11 Dec
'14
2:40 p.m.
On 11 Dec 2014 at 14:03:59, Marius Dumitru Florea
(mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:
You’ll always have edge case needs where having some script will help you.
BTW it’s true that LESS can replace velocity to some degree (since you can set some
variables and reuse them for example) but it’s quite primitive compared to Velocity and
all our java API behind and it’s also a lot lot less performant. LESS is a pain on
performance and the more we can avoid it the better. Also we’re not guaranteed that LESS
will be here to stay…
On Thu, Dec 11, 2014 at 1:54 PM, vincent(a)massol.net
wrote:
My idea would be to have a default source syntax to be plaintext + macro (i.e. plaintext
but also support to specify macros, possibly using the same syntax as for XWiki Syntax
2.x).
On 11 Dec 2014 at 12:46:48, Ecaterina Moraru (Valica)
(valicac@gmail.com(mailto:valicac@gmail.com)) wrote:
I don't want to write {{less}} or {{css}} every time I do some
styling. Related to Vincent's comment:
As a designer I would want to be able to write CSS as simple as possible.
Then just write CSS directly :)
Already I need to know that I need to add my CSS
to a SSX object. I
wouldn't want to know that if I need to write LESS I need to use whatever
other object or macro.
That’s not CSS, that’s LESS.
Also I want a simple solution where the existing
CSS written to be easily
adaptable. If I need to use some FlamingoThemes variables, already is
complicated that I need to know that I need less.
So I'm not a fan of having the css in wiki syntax. I don't want to write
css with ruby, python or whatever. I was in need of velocity because back
then less didn't existed (so we didn't had variables, etc.)
Also I assume css and less would need different macros and maybe they would
need to be nested and mixed together, which is again more of a xwiki style,
but definitely not a 'web' style.
What’s the need for a CSS macro?
Thanks
-Vincent
I really don't think we need wiki syntax
(scripting macros
precisely) when writing style sheets.
Yes I didn’t express myself properly. I meant a Rendering Syntax (not Wiki Syntax).
No one has ever asked for this.
So I'm -1. As Caty said, users should be able to paste their CSS/LESS
code without doing any useless wrapping.
It’s very simple it boils down to only 2 possibilites:
1) Either you have a select box that you need to click to explain what your content is
about
2) or you have a context field only and you decide what it contains by using some type of
annotations (and in my first proposal the default was CSS since this is what a SSX object
is about, so for CSS you don’t need to specify anything).
Now 1) initially seems to be fine with “Syntax” combo with various options: “CSS”, “LESS”,
“CSS+Velocity”, etc. The only problem is that you’ll never be able to specify all the
syntax combination that exist.
2) makes it even more easy than now to write pure CSS (since it removes the velocity
checkbox and you paste CSS directly) but also allows extending with other more exotic
features such as LESS, SAAS, scripting, include (so that the content is defined on some
other pages and can be reused between SSX)
It's a big difference between
the content of a wiki page and the style sheet object. I want to be
able to use wiki syntax in the content of the wiki page because it
doesn't have any specific purpose.
There’s no difference at all. Whenever you have a text area you need to put content in it
that’s of a given syntax, whatever the syntax! This is exactly the same for a wiki page.
The content can be used to generate
HTML, JSON, XML, whatever, depending on the application.
A wiki page generates content in XHTML. A SSX text area generates “CSS” syntax as output
(which can be assimilated as plaintext for our need).
On the other
hand the style sheet extension object has a very specific purpose. It
should be very easy and really straightforward to use it (e.g. "don't
make me think”).
I don’t see why this would be a privilege of a SSX. This should be true for any part of
xwiki, be it for writing the content of a page or anything else.
And BTW having 2 checkboxes to choose from all the time (one for parsing and one for the
CSS preprocessor to use) even when you all you need is simple CSS isn’t simplicity for me…
My solution is actually simpler than what we currently have and simpler than GD’s proposal
when the need is to use CSS.
PS: Saying
that you’ll never need scripting is just wishful thinking IMO… I can already find tons of
use cases where you’d need it (not even counting the many places we use velocity in our
SSX)...
From my experience we don't use scripting that much in SSX objects.
And when we do, it really boils down to:
(1) color theme variables, which will be replaced by LESS variables
(2) getting the URL of some internal resource (getSkinFile /
getAttachmentURL). For this, if we want to get rid of scripting we can
introduce a special syntax for the url('xyz') CSS value:
background-image: url("skin://icons/xwiki/create-link.png");
background-image: url("attach://myOwnIcon.png”); In any case, +1 for Guillaume's proposal (adding a
new property to the
SSX object).
So to sum up I’m less against having a “Syntax/Content Type” combo specifying what syntax
the Code property will contain with 2 values for now:
- CSS
- LESS
This removes the need for a {{less}} macro (which could potentially be useful if you want
to write a <script> tag in the content of a wiki page and use LESS content to
generate the CSS but that’s another story…).
However, the problem of scripting remains but can be fixed with what I mentioned above,
i.e. introducing a plaintext + macro syntax that would allow to enter CSS or LESS content
and still be able to use xwiki macros if the user wants/needs it.
Thanks
-Vincent
Thanks,
Marius
> Thanks,
> Caty
>
>
> On Thu, Dec 11, 2014 at 1:03 PM, Guillaume "Louis-Marie" Delhumeau <
> gdelhumeau(a)xwiki.com> wrote:
>
> > I would like to add some precisions.
> >
> > Most of my work during this week was on the LESS Module to be able to
> > compile (with a cache mechanism) any kind of resources and not only files
> > anymore.
> >
> > Thanks to that, my prototype of SSX implementation was easy to do in 2
> > hours or so, and I believe using my refactored API in any other
> > implementation (new xobjects, etc...) could be done quickly.
> >
> > So I am not asking you to accept an already-written-solution and we can
> > still discuss :)
> >
> > What Vincent proposes seems to be a good idea. However, after some
> > discussions with him, it would require an amount of work that is not
> > compatible with the current release date.
> >
> > So my actual proposal is the following:
> >
> > - Modify the SSX object to introduce the LESS preprocessor, as I have
> > proposed previously, as a temporary solution/hack.
> > - In the future (7.x maybe?), deprecate the current SSX object and create a
> > new SSX object that will use the wiki syntax. Create a {{less}} macro too
> > to be able to use LESS everywhere (in new SSX objects but also in the
> > XDOM).
> >
> > I hope you like this idea,
> >
> > Thanks,
> >
> > 2014-12-11 11:29 GMT+01:00 vincent(a)massol.net :
> >
> > >
> > >
> > > On 11 Dec 2014 at 11:08:16, Ecaterina Moraru (Valica) (valicac(a)gmail.com
> > > (mailto:valicac@gmail.com)) wrote:
> > >
> > > > Why do we need to add a new essx one? IMO we just add the new
property
> > > and
> > > > make sure the default value for 'CSS preprocesor' is
'none’.
> > >
> > > I think you didn’t read my proposal because I explained why :)
> > >
> > > The solution with CSS preprocessor is a hack, doesn’t always work as
> > > Guillaume pointed out and doesn’t support all future use cases.
> > >
> > > The solution I proposed solves all the needs, a lot more, and goes in the
> > > general direction where we remove all places in xwiki where we support
> > only
> > > one specific language and replace that by wiki syntax (and thus support
> > all
> > > existing languages). In this case, it’s not normal that we support only
> > > velocity and my proposal not only solves this but also solves using the
> > > LESS processor or any other thing you wish to do.
> > >
> > > Thanks
> > > -Vincent
> > >
> > > > Thanks,
> > > > Caty
> > > >
> > > > On Thu, Dec 11, 2014 at 11:59 AM, vincent(a)massol.net
> > > > wrote:
> > > >
> > > > > Note that if we don’t want to break backward compatibility we
keep
> > the
> > > > > current ssx and deprecate it and introduce a new essx one (for
> > extended
> > > > > ssx, or any other name…).
> > > > >
> > > > > Thanks
> > > > > -Vincent
> > > > >
> > > > > On 11 Dec 2014 at 10:54:46, vincent(a)massol.net
(vincent(a)massol.net
> > > (mailto:
> > > > > vincent(a)massol.net)) wrote:
> > > > >
> > > > > > Hi Guillaume,
> > > > > >
> > > > > > This is not a domain I know well so maybe what I’ll say is
not
> > > correct..
> > > > > :)
> > > > > >
> > > > > > What about keeping the exact same xobject structure as now
but
> > > instead
> > > > > of considering the content of the textarea to be plain text we
> > > consider it
> > > > > to be wiki syntax that is rendered using our plaintext renderer.
> > > > > >
> > > > > > This would allow use to use any more (including the
{{velocity}}
> > > macro,
> > > > > {{include}} macro, etc) but it also allows us to introduce some
new
> > > > > {{less}} macro that would preprocess its content and generate
CSS.
> > > > > >
> > > > > > This would also allow us to remove the “parse” option which
tells
> > us
> > > if
> > > > > we run velocity or not (this is actually bad since we may want to
run
> > > ruby,
> > > > > python, groovy, etc).
> > > > > >
> > > > > > WDYT?
> > > > > >
> > > > > > Thanks
> > > > > > -Vincent
> > > > > >
> > > > > > On 11 Dec 2014 at 10:20:49, Guillaume Louis-Marie Delhumeau
(
> > > > > gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
> > > > > >
> > > > > > > Hi.
> > > > > > >
> > > > > > > Since the beginning of the week, I am working to have
the LESS
> > > > > > > pre-processor inside our Skin Extension objects (see:
> > > > > > > http://jira.xwiki.org/browse/XWIKI-10708). It would
enable us to
> > > use
> > > > > the
> > > > > > > Flamingo Theme variables and all bootstrap's mixins
inside SSX
> > (see
> > > > > > > http://jira.xwiki.org/browse/XWIKI-11374).
> > > > > > > Example of use-case:
http://jira.xwiki.org/browse/XWIKI-11408
> > > (Menu
> > > > > > > Application: Improve default look to make it
better-looking with
> > > the
> > > > > > > Flamingo skin).
> > > > > > >
> > > > > > > I have created a design page there for the details:
> > > > > > >
> > > http://design.xwiki.org/xwiki/bin/view/Proposal/LESSModuleImprovements
> > > > > > >
> > > > > > > I propose to add a new property inside the
> > > XWiki.StyleSheetExtension
> > > > > class
> > > > > > > which will be called "CSS preprocessor". The
actual possible
> > values
> > > > > would
> > > > > > > be "LESS" or "none", but in the
future we can imagine having
> > > "SASS" or
> > > > > > > anything else. Then I propose to change the actual SSX
action to
> > > > > perform a
> > > > > > > LESS compilation if needed. Note that the user would
still be
> > able
> > > to
> > > > > use
> > > > > > > or not Velocity in addition of the CSS preprocessor.
> > > > > > >
> > > > > > > The other possibilities (that are not part of this
proposal) are
> > to
> > > > > create
> > > > > > > a new XWiki.LESSStyleSheetExtension and a new LSSX
action which
> > > would
> > > > > > > behave exactly as the previous objet and action, or to
have the
> > > > > ability to
> > > > > > > choose the processor directly inside the SSX content,
with a
> > > special
> > > > > line
> > > > > > > like "# preprocessor = less" or something
like that.
> > > > > > >
> > > > > > > I have made a prototype that is working (
> > > > > > >
https://github.com/xwiki/xwiki-platform/tree/feature-less-ssx)
> > > and I
> > > > > am
> > > > > > > taking care of the compatibility with older skins that
do not use
> > > LESS
> > > > > > > (Colibri for instance).
> > > > > > >
> > > > > > > Here is my +1. I would like to commit it today to have
it in
> > > 6.4M2. I
> > > > > have
> > > > > > > done a lot of refactoring on the LESS module (with a
better cache
> > > > > system
> > > > > > > among other things) that I don't want to commit in
a release
> > > candidate.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > --
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs