You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just wanted to start a discussion around FormExtensions and Bootstrap3.
I think we need to identify how will the migration will be done. IMO, we cannot "change all forms" and break BS2 compatibility.
Actually, I think we should be able to handle both: BS2 and BS3 at the same time. Difference is mainly based on "rendering" and views. Not on components/Javascripts themselves (well, not always, I agree). But FormTypes will almost not be different.
So, I see two ways to handle that:
Creating dedicated branches for each BS version. Advantages is it will be surely easier to use and maintain for BS3. Like for AdminGen, we simply make a tag 1.0 for BS2 and 1.1 for BS3 and go... Drawbacks: I think this means no more support on BS2 because we will be more focused on BS3 (which is normal...)
Keeping both compatibilities, and adding some Bundle configuration to specify if we should use BS2 or BS3 assets / form_widgets. Advantages: when we fix bugs on Transformers and Forms themselves, both BS2 and BS3 will benefit from the fix. Drawback: probably more complicated to maintain.
At least, if we just say "let's go for BS3, forget BS2), we should create different tags (for BC).
Discussion is open, please comment, tell what you think, ...
The text was updated successfully, but these errors were encountered:
@sescandell I prefer the first way. I personally am switching to BS3, and I will continue working on the BS3 branch. I do not have time to develop BS2 branch, BUT if there are active contributors to that branch I won't stop them. Haveing seperate branches makes it easier for me (I don't have to worry about configuration/compability with BS2) and for anyone interested in BS2 branch (they don't have to worry about configuration/compability with BS3).
I am finishing major update for this bundle, which I planned to push to master and BS3 branches (ofcourse, creating a seperate BS2 branch before merging anything to master).
The update I'm working on contains several BC breaks (but easy to upgrade):
changed all alias prefixes from afe_ to s2a_ - the bundle was moved under Admingenerator organization and from the very start was created mainly for admingenerator users -> s2a is a shortbut for Symfony2Admingenerator
changeing Bundle name from AvocodeFormExtensions to AdmingeneratorFormExtensions for the same reasons as above
removeing daterangepicker type: this form type was created to handle admingenerator date filtering and will be no longer necessary, as Admingenerator BS3 branch will also get a major filters update
replaceing date picker, time picker and datetime picker types -> they will use https://github.com/Eonasdan/bootstrap-datetimepicker as it is BS3 compatible and more easily configurable
renameing icon classes from icon-plus (FontAwesome 2 format) to fa fa-plus (FontAwesome 3 format)
update select2 library to newest version (3.4.0 -> 3.5.1) whioch is BS3 compatible
rename the twig functions form_stylesheet() to form_css() and form_javascript() to form_js() and move them to a seperate library (as AdmingeneratorGeneratorBundle will also need it for new filters functionality, but we don't want a hard dependency on FormExtensions bundle)
Hi everyone,
I just wanted to start a discussion around FormExtensions and Bootstrap3.
I think we need to identify how will the migration will be done. IMO, we cannot "change all forms" and break BS2 compatibility.
Actually, I think we should be able to handle both: BS2 and BS3 at the same time. Difference is mainly based on "rendering" and views. Not on components/Javascripts themselves (well, not always, I agree). But FormTypes will almost not be different.
So, I see two ways to handle that:
At least, if we just say "let's go for BS3, forget BS2), we should create different tags (for BC).
Discussion is open, please comment, tell what you think, ...
The text was updated successfully, but these errors were encountered: