On 12 Dec 2014 at 11:56:27, Ecaterina Moraru (Valica)
([email protected](mailto:[email protected])) wrote:
> 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
We should have a property that tells what the “code” textarea contains. That’s
the “Content Type” property and the 2 values displayed should be CSS and LESS.
> After the expanding we can just rename the pretty names to: 'Content Type':
> LESS, CSS, etc.
It has nothing to do with pretty names and no, we should not go over a
migration of structure.
> Not sure why we should have now an ambiguous naming, just for the sake of a
> possible future expansion.
I don’t understand what’s ambiguous in letting user decide if they want to
enter CSS or LESS code.
Please state what you find ambiguous.
Thanks
-Vincent
> Thanks,
> Caty
>
>
> >
> > I have nothing against this. Do everyone agree?
>
>
> > 2014-12-11 15:54 GMT+01:00 Thomas Mortagne :
> >
> > > 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]" 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
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
