Closed ghost closed 11 years ago
Yay!
Hooray
That's what I have wished for a long time. Now I hope that we can implement it technically.
We need someone to do it. I was hoping @jusuff could but he might not have time in the foreseeable future. The plan is to lose Prototype hard, with no BC in 1.4.
There are some other parts to the jquery libs that we wil need to include. I will be building a pull request in the future for this.
jQuery and JQuery UI do not include all the exact same functionality as our current solutions (tooltips for example). If the desire is to maintain the functionality, some additional plugins for jQuery may need to be included.
We must decide which UI we want to use. Afaik the jQuery UI is/was huge with a lot of files. I don't know exactly.
But if we planned to add the Twitter Bootstrap (refs #347) to the core, then we have redundant effects, functions, modals, dropdowns and more.
this discussion: https://groups.google.com/d/topic/zikula-dev/-NIHWivHpxU/discussion
and specifically this post by @jusuff : https://groups.google.com/d/msg/zikula-dev/-NIHWivHpxU/6d4t5zpcoaYJ
led me to believe that there really was no question about the UI is to be included. Jusuff only mentioned jQuery UI. I have been working with it and intend to submit a PR which will include it along with some other elements.
regarding script 'weight' - jusuff essentially says it is a non-issue.
The twitter bootstrap UI might be a better choice imo. http://twitter.github.com/bootstrap/javascript.html (docs) and https://github.com/twitter/bootstrap/tree/master/js (source)
This seems like an important choice to be taken lightly. What are the available UI candidates? jQuery UI and Twitter UI? Which one is a) more supported ? b) easier to use ? c) lighter on resources ?
Also is this about what to include in the core or about what to actual use in the core?
The "jQuery UI Bootstrap" project was already mentioned by craigh in refs #347 .
The developer has created a blog article (http://addyosmani.com/blog/jquery-ui-bootstrap/) where he is talking about the same problem.
I like his approach, but the main problem is: What happens if this developer stops the development of his project? Then we don't have bridge between the projects "Twitter Bootstrap" and "jQuery UI".
I guess it doesn't make sense to me at all to choose anything over the 'native' UI - e.g. jQuery-UI. This one is directly connected and supported by the same group as jQuery and makes the most sense. This should be included
I am currently talking with Jusuff about the new orientation and the decision. We are not sure yet, but it looks like we should not add the jQueryUI themes.
We can try the following combination:
the full jQuery-UI includes all the widgets
I think the themes should be included. otherwise developers will be littering their choices all over the modules. In addition, the site admin won't be able to easily choose which theme they would prefer on their site to match their site's theme. IMO, they should all be available and there should be a system ModVar that selects a jQuery theme. This can then be available to module devs to use within their module.
it also doesn't make sense to not include the stock themes but include the bootstrap theme. either include them all or none.
@jusuff and @hvorragend I checked about this issue of jQuery UI and Bootstrap css - it seems that bootstrap have fixed the issues in 2.0. See https://github.com/twitter/bootstrap/issues/171
Yes, twBootstra should work with jQuery UI without conflicts. But I want to test it first. What's more - I want to check what options we have if we would like to use both - jQuery UI (as much more featured UI framework) and twBootstrap (mostly as CSS bootstrap, but also with some additional js plugins).
Of course, specifically I am referring to the fact that it is not necessary to use a special theme now in order to use jQuery UI with Twitter Bootstrap in that ticket reference.
It seems unnecessary that we are both compiling similar pull requests. I suggest we work together on the same somehow.
@drak and I chatted last night and brought up several issues and questions which need to be discussed. It is unclear to us if the jquery themes will have any of their styles overriden by a site theme. This question needs to be answered and is part of the reason why I suggested including all the themes.
If the jquery themes are wholly independent of any other css (including the site theme css and core css) and not affected by it, then that would be an argument for including more jquery themes with the core. For example, what if my site is dark green and yours is pink? we would prefer different jquery themes to help match our site theme.
One idea I had was to choose maybe three jquery themes to bundle with the core - a light grey, a dark grey and a blue that matches Andreas08 (and maybe also the twitter one). Then put a chooser somewhere (maybe the theme module) that the site admin could select which one they wish to use. This would give the site admin some flexibility. If that chooser were to scan our jquery/theme directory for options then a site admin could easily add others if they wish and choose that one also.
I don't mind only including a few jquery themes, but we need to provide some flexibility for site admins while also providing a global variable for the site admin's selected jquery theme.
but in the end, we need to understand better how the css files interact between the jquery themes and zikula themes. I was hoping @hvorragend and @jusuff would be able to shed some light on that.
I was hoping for some comments on this from @hvorragend @jusuff so that we could resolve the matter. I'm willing to do the work and rework the PR if needed, I just need to know what we are going to do.
Craig - need more time to comment this topic. Need to check some things about twBootstrap and jQuery Ui.
Here are two jQuery-based smarty template plugins which are ready for the core when jQuery-UI is added:
in addition, I've added a lot of jQuery-UI goodness to PostCalendar in the 7.1.0 branch. Specifically to the New event creation page and to the user navbar. In order to view them at the moment, you have to pull my jQuery_improvements branch of the core because it is depending on the changes I have made there.
so this would explain my support of jQuery-UI over other UI frameworks. I've already implemented it.
@espaan
been playing a bit with bootstrap. I'm trying to use just the tooltip jQuery plugin. This requires the bootstrap.css file which in my opinion (albeit somewhat uninformed) is a real problem. The boostrap.css file overrides many styles I already have in place and makes more work to 'fix' everything that it 'breaks'. Perhaps it is simply a load-order problem, but if is loaded by a module, will it not be loaded after core and module stylesheets, thereby overriding them? Simple things like setting a font-family on the body are a real problem for me.
https://github.com/twitter/bootstrap/blob/master/docs/assets/css/bootstrap.css#L135
@craigh - The plan from 1.4 is to switch from using our own zikula css to bootstrap. For 1.3 maybe it's not viable, but from 1.4 refactoring will be required. Saying that, I don't want to introduce new things in 1.3 that are going to require immediate change next version, hence the conservative-ness. That's why this ticket is set to the 1.4 milestone.
The plan from 1.4 is to switch from using our own zikula css to bootstrap.
hmmm. I thought this was a discussion about options. I didn't realize the decision was decided.
JQuery-UI doesn't appear to require such changes.
It is about options, nothing is final except we are definitely switching from prototype to jQuery in an immediate BC break and dropping the Zikula UI for something else. This thread is getting complicated by the bootstrap discussion although it's quite relevant of course. Changing our framework css will of course break everything, as will switching to Twig which is why the discussions are complicated. It's further complicated because actually, the plan was never to add jQuery UI to Core 1.3, only to maintain jQuery. We are jumping the gun here as we do not need jQuery UI in 1.3 because we have Zikula UI. 1.3 is not a feature branch, although we allow some minor feature additions. I dont want to be a stick in the mud regarding progress, but really, I feel this discussion is overly complex because we're sort of talking about 1.3 when we shouldnt be.
I've check Twitter Bootstrap with jQueryUI. Haven't found conflicts. Both works well. The only issue would be visual inconsistency - both use different themes so for example buttons from twBoostrap would look different then jQueryUI buttons. We cannot use "jQuery UI Bootstrap" project, because it's already outdated (it's build for some previous twBootstrap versions and wont work with current version). But we could create own jQueryUI theme, adjusted to twBootstrap.
So - in my opinion - we definitely should use jQuery UI. It's more featured UI library. Twitter Bootstrap plugins are nice (sometimes could be more useful than jQuery UI as they are simpler) but this is not full-featured UI library. If we decide to use twBootstrap as CSS framework - then we could write own jQuery UI theme (this would be the best solution for me :) ).
And about jQuery UI themes - I don't think we should include more then one theme. Chosen theme should be consistent with used default admin theme. Chose one and use it. If someone would like to change it - there's no problem with downloading it from jQuery UI site. Adding to core more jQuery UI themes wont give flexibility if this theme's wont be adjusted to default admin theme.
The conflicts I've found have more to do with CSS I think, not JS. But I am not entirely certain. in my very limited testing I found Bootstrap 'took over' the styling of too many elements on the page. It didn't limit itself to strictly its own widgets.
@craigh - Twitter Bootstrap styles everything because it's CSS framework - is should style whole page.
What I would like to see is the following:
z-
naming strategies for this.Making bootstrap the root of our CSS we can easily and simply style whatever we like, Bootstrap UI, jQuery UI, etc. It can all be done from the convenience of a zikula theme.
I know @craigh there are some difficulties right now but that's because you're dealing with it in 1.3, from 1.4 we would be starting fresh as it were.
The PRs are all for the master branch zk2,0 right? There is no need or option to update modules already is there?
You can already code now with jQuery. But because the most of the functions still need prototype it is better not to migrate the scripts now (otherwise both libraries are loaded).
exactly, thanks. But for the frontend I could already do a lot with jQuery. Have to dive into my e-books :-)
both libraries are not automatically loaded. you can choose which you wish to be loaded. There are already two jquery based plugins in the core - datepicker and timepicker
Does jQuery UI contain some functionality for client-side form validation? We will need some replacement for validation.js which is prototype-based.
I found this from a cursory seach http://docs.jquery.com/Plugins/Validation
Also take a look at the article described in teh plugin page, interesting. http://bassistance.de/2007/07/04/about-client-side-form-validation-and-frameworks/
The whole Form framework should use this (or another jQ solutoin) then as well right ? Formicula uses for instance the Form validation stuff AFAIK.
2013/2/7 Erik Spaan erik.spaan@gmail.com
Also take a look at the article described in teh plugin page, interesting.
http://bassistance.de/2007/07/04/about-client-side-form-validation-and-frameworks/
With respect to forms, we'll moving to Symfony Forms in time: http://symfony.com/doc/master/cookbook/form/index.html
I see that the way of calling the validation for prototype validation is not that different from jqeury validation with the validation plugin. So for formicula that should be not so much of a problem.
I see that Symfony forms are quite different if we are also going to be using Twig. I see that there are plugins available that use the jQuery validation plugin alongside Symfony 2 Forms: http://blog.jimmyweb.net/developer/sfjqueryformvalidationplugin-a-client-side-form-validation-plugin-for-symfony/
Should zikula.ui be replaced by jQuery too?
Hi, I think Jusuff is working on that but only for Zikula 1.4 afaik.
It was just a general question for my modules. So should zikula.ui be replaced?
Hi, I think jusuff is remaking zikula.ui to use jquery. AFAIK it will stay active in the future. But in modules you can also use jQeury.UI directly if that works. Then you're also good to go.
@jusuff can you reply ?
it's more a question of appropriate use. zikula.ui is specific to Zikula and makes using parts of it easier and is already themed to Zikula. jQueryUI is a general use library that can do many things (some things the same as Zikula.ui) but it isn't specifically tied to zikula's "look and feel". I believe @jusuff will be rewriting Zikula.ui to jquery and so then you can still use it.
Ok. That answers my question.
Zikula.UI will be rewritten, but it will be still avaiable. Most important change is it will be based on jQueryUI instead of LivePipe.
If this is done: what is the replacement for validation.js ?
If there is no answer please reopen!
@jusuff - what is the replacement for validation.js
in jQuery?
I like http://blog.jimmyweb.net/developer/sfjqueryformvalidationplugin-a-client-side-form-validation-plugin-for-symfony/ mentioned by @espaan as it is a very elegant approach (reusing server-side validation rules).
Remove Prototype/Scriptaculous and refactor all code to jQuery 1.7 + UI