On Thu, Dec 11, 2014 at 5:03 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
> So the field would be called "Content Type" with these 2 following options: > "CSS", "LESS". > You can name the property 'contentType' but until we expand the functionality, the pretty names could still be: - CSS Preprocessor: LESS, none After the expanding we can just rename the pretty names to: 'Content Type': LESS, CSS, etc. Not sure why we should have now an ambiguous naming, just for the sake of a possible future expansion. Thanks, Caty > > I have nothing against this. Do everyone agree? > 2014-12-11 15:54 GMT+01:00 Thomas Mortagne <[email protected]>: > > > 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) 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. > > Le 11 déc. 2014 15:06, "[email protected]" <[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 > > > > > > -- > Guillaume Delhumeau ([email protected]) > Research & Development Engineer at XWiki SAS > Committer on the XWiki.org project > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
