Menu
▾
▴
Re: [Tikiwiki-devel] JQuery branch merge options/review
|
From: <ma...@gm...> - 2009-03-01 22:51:18
|
+1 MatWho On 1 Mar 2009, at 04:12, Marc Laporte wrote: > Hello all, > > Earlier today, during the TikiFest, we had a 1-hour conference call > about jQuery and quicktags. I also had long discussions with Matthew > and Jonny at the TikiFest in Madrid. > > Picking a JS Framework is a strategic decision. This will influence > the future of our evolution as the UI will become richer & nicer. > > Here is a proposal. This also covers the discussions over the last > few months. > > Considering: > 1- The general consensus is leaning towards using jQuery as the future > main JS framework > a) Some devs are volunteering to maintain it > b) Some people are very positive about it. > c) Some people are fine to use either or Mootools or jQuery or even > others. > d) Most people are silent > e) No one has really expressed anything against jQuery. > f) jQuery & Zend: > http://framework.zend.com/manual/en/zendx.jquery.html and we have > already gone the Zend route. > > > If we had to start from scratch, the obvious choice would be jQuery. > The main point being that we have some people that are volunteering to > maintain it. The second big point is that some of our designers are > excited and what I am hearing is that, overall, jQuery makes it easier > for designers to use JS. > > > 2- Many people have expressed concern however with having duplicate > code/libs. We had a similar discussion when picking between FCKEditor > and TinyMCE. I think avoidance of code/feature duplication is one of > our strengths. This helps us have a lot of features without going > completely bonkers trying to maintain all the possible > permutations/interactions. So it's a choice between jQuery and > Mootools. > > > So it's increasingly clear that it's not IF jQuery but WHEN and HOW. > > > 3- Considering a jQuery branch has been running for quite a while now. > > 4- Considering we are in release mode. (branches/3.0 was just created) > > 5- Mootools is already in the code > a) At least one person (Tom) has expressed explicit support for > Mootools. However, this is to use Mootool goodies which are not > released in the main version of Tiki. So while this is very > interesting, it is not something which is accessible to the larger > community. > b) No one is committed to actively maintaining it. For example, we > have two version of Mootools in Tiki. > c) While Mootools is used for a few things in Tiki, it's not to the > point where it is irreversible. Matthew & Jonny are very active with > jQuery and intend to migrate all the current Mootools goodies to > jQuery. (in addition to introducing quite a few new goodies that they > feel are easy to do with jQuery) > > > Proposal > 1- For jQuery to become the official, always-on in 4.0 > a) It should be always on if javascript is detected. We don't want > people developing features, which then break when jQuery is turned on. > 2- As a transition, for jQuery to be added as soon as possible > (hopefully within a few days) to 3.0 as experimental, default to off > 2a) This should provide the same behavior as now. If not, Jonny will > add all the feature checks to do so. So, all users that want > stability, and don't care for fancy new stuff, are protected. > 2b) It will provide early adopters a way to test and dogfood. > 2c) Theme designers will be right away able to design themes which > leverage jQuery without heavy maintenance. > 3- For jQuery to use the compatibility mode, to make it easier for > people who want to combine with other things. > 4- For all code (autocomplete, shadowbox, etc.) to be moved from > Mootools to jQuery in time for 4.0, and the 2 Mootools libs to be > removed from the main code base and any interesting code to be added > to mods. jQuery would continue to use compatibility mode in the > future. > > > This seems to me as the "delicate balance" compromise which takes into > account the various > goals/pressures/wishes/desires/opportunities/threats. It's a solution > which may not make any single person super happy, but I hope it's > something which is acceptable for everyone. > > 3.0 is due in April. If during March, it looks like jQuery is working > out very well, all the bugs are getting fixed quicky, and the majority > consensus is that it's stable enough, we could move it out of > experimental (but still optional). This will be up to the jQuery > advocates to make us all want it :-) > > > I will be dogfooding 3.0 site with jQuery on & off to test both. > > Best regards, > > M ;-) > > > On Fri, Feb 27, 2009 at 6:29 PM, luci aka luciash d' being <sf...@gr... > > wrote: >> hi jonny, >> >> On 02/27/2009 08:48 PM, Jonny Bradley wrote: >>> Hi all >>> >>> Sorry if this sounds a bit bossy - these things up are all up for >>> discussion, but it's good to work out where we're heading, so >>> forgive >>> me for being forthright. >>> >>> The general consensus in Madrid (and on this list?) seemed to be >>> that >>> branches/experimental/jquery should be merged into trunk *before* >>> 3.0, >>> and JQuery should eventually become the de-facto JavaScript lib for >>> tiki 4.0 (ok, one consensus and a proposal ;) >>> >> i agree it should be done asap if we really want it in 3.0 >> >>> JQuery will run in compatibility mode for now, so MooTools continues >>> to function if needed (including on customised stuff external to >>> tiki). Some of the plugin bits i've implemented today need more >>> testing in this respect, but the intention really is for people to >>> use >>> one or the other. >>> >>> JQuery should be enabled by default if JavaScript is enabled, and >>> Moo >>> disabled, providing i/we can port the current moo-functionality in >>> time (mainly page slideshow [still todo], page name autocomplete >>> [done] and plugins editor [done]). >>> >>> Thanks Luci for the pointers to the superfish and reflection >>> plugins - >>> superfish is in there (but needs more admin options imho - not sure >>> what to do with reflection - more here: http://www.digitalia.be/software/reflectionjs-for-jquery) >>> >> i imagined it could be used similarly like shadowbox (some param) >> where >> necessary, e.g. on the site logo (so i don't have to render those >> reflections in every logo i draw) >> also it could be applied on the admin sections icons, etc. >> users could use it as effect in galleries or apply it on images in >> wiki >> pages... >> >> >>> I think i should do the merge before doing much more so that others >>> can play too (it's fun!) and so any problems show up, and get fixed, >>> sooner (also i'm hitting more and more files so updating from >>> trunk is >>> becoming increasingly uncomfortable). >>> >>> Could someone who's done this before have a quick look over what >>> will >>> be affected by this, to make sure i don't do nothing foolish? TIA! >>> >>> Finally... i think there should be a 4th rule: "merge soon!" >>> One tiki, under a groove, etc ;) >>> >> heheh :) >> >> luci >> -- >> :. :.: ::: : >> luciash d' being aka Lukas 'luci' Masek >> mail: luci2009 [ᴂt] ground.cz >> >> >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San >> Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a $600 discount off the registration fee with the source >> code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Tikiwiki-devel mailing list >> Tik...@li... >> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel >> > > > > -- > Marc Laporte > > http://MarcLaporte.com > http://TikiWiki.org/MarcLaporte > http://AvanTech.net > http://OurWiki.net > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San > Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source > code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Tikiwiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel |