Btw, the Distribution Wizard steps (templates) are written in wiki syntax. So Thomas already did some work in this direction.
Thanks, Marius On Wed, Feb 26, 2014 at 1:35 PM, [email protected] <[email protected]> wrote: > I agree that it would be nice if we could use our rendering engine. > > Note that we'd need to implement a new macro to include another page from the > filesystem (ATM the {{include}} macro only supports including wiki pages). > > We'd need to evaluate the cost of moving from our velocity templates to our > rendering engine since we need to have a new skin fully production ready by > the end of 6.x which means having it done several releases before the end to > iron out all the issues (I'd say by 6.2). > > Thanks > -Vincent > > On 26 Feb 2014 at 10:52:35, Denis Gervalle ([email protected]) wrote: > > 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 < > [email protected]> 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, [email protected] <[email protected]> >> wrote: >> > 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) ([email protected] >> (mailto:[email protected])) 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 >> >> >> >> >> >> > >> >> > WDYT ? >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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 >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > Denis Gervalle > SOFTEC sa - CEO > _______________________________________________ > 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
