11 Dec
2014
11 Dec
'14
3:46 p.m.
I'm +1 for the first proposition of Guillaume. We lived for a few years with
only CSS in StyleSheetExtension objects and not XWiki syntax (or Rendering
Syntax, I don't really know the difference). Having LESS will add a significant
improvement and we can still think about something else later.
And I agree that, as a developer (sometimes), I would prefer to type only CSS or LESS
instead of wrapping
my code inside a macro.
@Marius, I like your idea of url('attach:something') :-)
Hope this helps,
On Thu, Dec 11, 2014 at 03:06:20PM +0100, vincent(a)massol.net wrote:
On 11 Dec 2014 at 14:49:18, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
--
Jean Simard
jean.simard(a)xwiki.com
Research engineer at XWiki SAS
http://www.xwiki.com
Committer on the XWiki.org project
http://www.xwiki.org
On 11 Dec 2014 at 14:40:31, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
Note: There’s a problem with my logic: the XDOM is not meant to be a generic
representation of any syntax… Its done for textual content only (heading, section,
paragraphs, words, etc) so it’s not well adapted to any kind of syntax… So it works for
textarea supposed to represent text only...
Thanks
-Vincent
On 11 Dec 2014 at 14:03:59, Marius Dumitru Florea
(mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:
BTW on a different but related topic we will need in the future to have some metadata to
let the user specify what syntax he’s using when filling the context of a text area. The
need is double:
- let the user decide the syntax of the content he’s entering
- let the developer of the xproperty decide what syntaxes are supported (to limit the
list of proposed syntaxes to the user) On Thu, Dec 11, 2014 at 1:54 PM,
vincent(a)massol.net wrote:
>
>
>
>
>
> On 11 Dec 2014 at 12:46:48, Ecaterina Moraru (Valica)
(valicac@gmail.com(mailto:valicac@gmail.com)) wrote:
>
>> 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 don't want to write {{less}} or {{css}} every time I do some
styling.
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).
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.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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”);
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…
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