On Thu, Dec 11, 2014 at 4:41 PM, [email protected] <[email protected]> wrote: > > > > > > On 11 Dec 2014 at 15:54:52, Thomas Mortagne > ([email protected](mailto:[email protected])) wrote: > >> Guillaume is about to introduce a way to indicate what is the content, I >> would suggest to name this field in something more generic than pre >> processor (for example content type) > > Yes, this is what I suggested :) > >> and we can add more stuff to that list >> later the default staying none. Vincent can add wiki to that list if he >> really wants it would stay an optional type and everyone is happy IMO. > > Actually I don’t want wiki! See my latest answers where I explained better > what I had in mind than in the first reply.
Sure, but this is another discussion for later. What I mean is that you can add anything you want later. > > Thanks > -Vincent > >> Le 11 déc. 2014 15:06, "[email protected]" a écrit : > >> >> > >> > >> > >> > >> > >> > On 11 Dec 2014 at 14:49:18, [email protected] >> > ([email protected](mailto: >> > [email protected])) wrote: >> > >> > > >> > > >> > > >> > > >> > > >> > > On 11 Dec 2014 at 14:40:31, [email protected] ([email protected] >> > (mailto:[email protected])) wrote: >> > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > On 11 Dec 2014 at 14:03:59, Marius Dumitru Florea ( >> > [email protected](mailto:[email protected])) >> > wrote: >> > > > >> > > > > On Thu, Dec 11, 2014 at 1:54 PM, [email protected] wrote: >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > On 11 Dec 2014 at 12:46:48, Ecaterina Moraru (Valica) ( >> > [email protected](mailto:[email protected])) 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. >> > > >> > > >> > > 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) >> > >> > 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 >> > >> > > Thanks >> > > -Vincent >> > > >> > > > > 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 >> > > _______________________________________________ >> > > devs mailing list >> > > [email protected] >> > > http://lists.xwiki.org/mailman/listinfo/devs >> > >> > _______________________________________________ >> > devs mailing list >> > [email protected] >> > http://lists.xwiki.org/mailman/listinfo/devs >> > >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
