12 Dec
2014
12 Dec
'14
12:07 p.m.
On 12 Dec 2014 at 11:56:27, Ecaterina Moraru (Valica)
(valicac@gmail.com(mailto:valicac@gmail.com)) wrote:
On Thu, Dec 11, 2014 at 5:03 PM, Guillaume
"Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
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.
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.
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 :
as
use
was
allows
purpose.
objects.
lot
http://lists.xwiki.org/mailman/listinfo/devs 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, "vincent(a)massol.net" a
écrit :
On 11 Dec 2014 at 14:49:18, vincent(a)massol.net (vincent(a)massol.net
(mailto:
> vincent(a)massol.net)) wrote:
>
> >
> >
> >
> >
> >
> > On 11 Dec 2014 at 14:40:31, vincent(a)massol.net (vincent(a)massol.net
> (mailto:vincent@massol.net)) wrote:
> >
> > >
> > >
> > >
> > >
> > >
> > > On 11 Dec 2014 at 14:03:59, Marius Dumitru Florea (
> mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com))
> wrote:
> > >
> > > > 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
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 > 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 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 > 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 It
to
> > > 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 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 > > > > 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 > 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