26 Feb
2014
26 Feb
'14
10:51 a.m.
Hi Marius,
I regards to the skin, I do not see why we would require another template
language. IMO we should get rid of all those .vm in favor of our rendering
engine. It looks now odd to have those templates bootstrapping our far more
evolved rendering system. We may of course integrate other scripting
languages that provides similar feature to the velocity macro.
Regards,
On Tue, Feb 25, 2014 at 11:58 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
+1 for a fresh look, so for Flamingo. Regarding the
templates, we need
to take into account that Velocity is starting to become an old
technology (last release is more than 3 years ago) so it may be a good
time to look for alternatives. On the server side there is FreeMarker
(last release in June 2013). We could also decide to use wiki syntax
in the templates. On the client side there are standalone libraries,
such as Handlebars used by Ember, or framework-specific
implementations like in the case of Angular.
Thanks,
Marius
On Mon, Feb 24, 2014 at 2:49 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
Personally all I know is that we need a fresh
look in XWiki 6.x so for
me there's no doubt that we want Flamingo.
What needs to be discussed is how to get there. There are 2 paths:
A) modify our templates/css heavily to use Bootstrap and base the new
Flamingo on
that
B) keep the current templates as much as
possible, with possibly some
changes and move templates specific to Colibri in the
Colibri skin and
templates specific to Flamingo in the flamingo skin, keeping common
templates in the templates directory. No bootstrap integration.
Pros and Cons of solution A:
============================
+ foundation for the future
+ allow us to perform cleanup of our templates
+ ability to use bootstrap themes (an issue we've had for a long since
so far
we've never been able to support more than 1 skin - We could do
color changes but not structural changes)
- more costly
- will take more time to have Flamingo ready for end users
- need to rethink the notion of Color Themes into a more global notion
of Skin
Theme which affects not only colors but also other parameters
(centered or not, etc)
Pros and Cons of solution B:
============================
+ less costly
+ quicker to get in the hands of our users and thus quicker adoption of
XWiki as a
product
- only able to support one skin as we've done
in the past
- not building for the future and not able to leverage the work done by
others on
bootstrap
Obviously A is the best option if you have all the devs in the world and
all the
time in the world... :) Personally I'd like and need to see an
evaluation of the work required to do A) before choosing anything. What can
be done in 6.0, 6.1, etc? In which XWiki release would we be able to see
Flamingo ready if we were to do A?
What is important IMO is to be able to show UI improvements/progress in
every
release of XWiki (6.0, 6.1, etc) since we've been lagging a bit
behind on this.
Thanks!
-Vincent
On 24 Feb 2014 at 09:44:57, Ecaterina Moraru (Valica) (valicac(a)gmail.com
(mailto:valicac@gmail.com)) wrote:
> On Sun, Feb 23, 2014 at 12:58 AM, Denis Gervalle wrote:
>
> > Hi Cathy,
> >
> > You have launch a couple of not so easy threads, and probably why no
one
> > have found enough time yet to follow up.
I really hope this will
change in
> > the upcoming days, since the skin
evolution is very important aspect
that
> > really need to be thoroughly discussed.
> >
> > As I see it, choosing between 1. "keeping the colibri look" using the
Junco
> > skin, and 2. using a fresh look like
flamingo, based on your developed
> > arguments, is more a question about what do we do with our current
> > templates, and how free are we to change them ? Could we afford and
impose
> > a new improvement to our markups and
templates, while providing enough
> > backward compatibility for existing extensions.
> >
> > In your Bootstrap integration thread, I develop the technical aspect
around
> > these markup issues, showing, I hope,
that we have the occasion to
smoothly
> > evolve our skin without getting stuck by
the past. Regarding the
design
> > aspect, your Flamingo proposal is far
more refreshing and appealing,
> > providing a more responsive look that I hope could extends our user
base.
> > If we could implement it without
extending bootstrap, allowing it to
be
> > restyled with any bootstrap variants, it
would make it a very
versatile
> > skin.
> >
> > So, if we could target that new skin, while keeping an acceptable
> > compromise for existing stuff, I see no reason not to move forward.
This
is
> > not really a choice between 1) and 2),
since what I propose is to use
Junco
> > to provide a backward compatibility CSS,
and for a while also a
modernized
> > colibri skin using our existing
templates, and to also evolve our
> > templates, using a more bootstrap based markups to produce that more
> > appealing Flamingo skin. So, it is more 2) than 1), since we will only
> > target 2) for new stuffs.
> >
>
> So what you are saying is that:
> - if someone wants a backwards compatible skin (with Colibri and with
> current extensions on e.x.o) should use Junco and
> - if someone wants a new skin (where we implement new functionality)
should
> use Flamingo.
>
> From your e-mail I understand that your preference goes towards
Flamingo.
> I admit that Junco is more of a compromise
solution for our problems and
> I've seen it as in intermediate step towards Flamingo, while still
> providing new functionality and making us advanced (in the shortest time
> possible).
>
> The issue is our development resources and I think it would be hard for
us
to
officially maintain 2 skins.
So maybe some solutions would be:
A. Officially: Colibri + Junco + Flamingo
- Maintain support for Colibri, but not innovate. We should support this
skin for 1 year at least;
- Support Junco, as in intermediary solution for Colibri and Flamingo;
- Support Flamingo (new stuff).
B. Officially: Colibri + Flamingo
- Maintain support for Colibri, but not innovate;
- Support Flamingo;
- Have Junco on e.x.o as a backwards compatibility solution.
C. Officially: Junco + Flamingo
- Stop support for Colibri since Junco will kind of duplicate it (while
adding the Bootstrap functionality);
- Support Junco
- Support Flamingo.
These are just ideas.
Thanks,
Caty
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
WDYT ?
_______________________________________________
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