Re: Open Discussion: remove Bootstrap from T5 core
Sounds good! We would need to document bootstrap usage locations, and classes therefor we could use any library. We could also add default class names to all locations where there was bootstrap classes with tap- prefix. Sent from my iPhone! Numa Schmeder > Le 15 févr. 2019 à 12:38, Jens Breitenstein a écrit : > > Thanks for you positive feedback. I suggest the following now: > > 1) I will use git hub to create a new T5 Fork based on Thiagos 5.5.0-beta-1 > and remove all bootstrap dependencies. As soon this compiles we will have a > T5.5 version looking like websites in the good old early 80ies. > > 2) I will try to get our own (unfortunately internal) website up and running > again, including the latest BS3, means all BS code is located in my client > (it is anyway, because we use a newer BS3). > > 3) Next I extract all BS3 related code to a new module, thus we have a plain > T5.5 without BS, a T5-BS3-extension and a sample APP using the BS3 css > classes / col definitions in TML code -> everything is like before, existing > code should still run without modifications. > > > > 4) I invite you to discuss the implementation details how we can best make > use of bootstrap related features without tight coupling so we can basically > change between BS3 and BS4. This means we need some way to handle BS related > differences like new / missing BS classes (for example panel) and we have to > support the different grid definitions aso. One way (for example) might be T5 > components to wrap most of the BS classes and each extension lib will take > care of the particular BS details. At the very end our TML code never sees BS > css classes at all, well at least for the "most common" things. We can start > this discussion right now, because this is the tough part to my opinion. I > would like to hear / read all your ideas. > > 5) We / I create a mini App using the new T5-BSx extensions do demonstrate > the use of the new BSx handling, we need it for testing / discussing anyway > (see 4) > > > We move over our disussion to github to avoid polluting the mailing list. > > Ok? > > > Jens > > > > > >> Am 14.02.19 um 14:07 schrieb Bob Harner: >> I agree that Tapestry shouldn't be so tightly coupled to a specific CSS >> framework. >> >> For context and some alternative ideas, see this prior discussion of the >> same topic: >> >> https://tapestry.markmail.org/search/?q=What+happens+when+Boootstrap+4+is+released%3F >> >>> On Thu, Feb 14, 2019, 4:52 AM Ben Weidig >> >>> Hi Jens, >>> >>> I like the idea of decoupling the core and Bootstrap to make it easier to >>> use other versions. >>> >>> Maybe the components should be updated to BS4 for T5.5, with a legacy >>> fallback or a component swap (can't remember the service doing it, we have >>> our own implementation, it's doing an advice on >>> ComponentClassResolver#resolveComponentTypeToClassName or >>> ComponentInstantiatorSource#getInstantiator). >>> >>> For 5.4 we've developed an internal solution for using different BS >>> versions, here are some specifics. >>> >>> We have multi-tenant-apps with different BS versions (so far up to 3), so >>> we needed a flexible solution that supports the internal BS and other >>> versions dynamically. >>> >>> To make it even more flexible we've added SASS-support and compile >>> Bootstrap from the source files, with the possibility to add files >>> beforehand to the compilation step with custom variables etc. >>> >>> The layout component has an annotation that triggers >>> a ComponentClassTransformWorker2 attaching a JavaScriptStack containing the >>> BS version decided by a contributable strategy pipeline. >>> >>> JavaScript modules were the biggest problems, we started with replacing the >>> internal modules, but ended up adding additional modules instead. This >>> worked fine after getting all the dependencies right, but every BS version >>> might break it again, so we're now using the bundled version of BS JS. >>> >>> We think this could all be cleaned up nicely if the internal BS wouldn't be >>> as integrated as it is right now. >>> >>> Eventually we will release it as open-source, but having an integration >>> into Tapestry (as a new tapestry-*) would be even nicer :-) >>> >>> Best regards >>> Ben >>> >>> >>> On Thu, Feb 14, 2019 at 10:14 AM Jens Breitenstein >>> wrote: >>> Hi Tapestry guys! I want to hear/read your opinion about getting rid of the Bootstrap Library from T5 core. I would like to move all BS related code (css/js) to a seperate module like "tapestry-bootstrap3" and decouple the hardcoded BS from T5. Furthermore I would like to see a second module "tapestry-bootstrap4" which uses BS4. From the sources I see direct dependencies are less than expected. Some tml's use it (I just ignore the internal T5 pages for now): AjaxFormLoop.tml class="btn btn-default btn-sm"
Re: Re: Open Discussion: remove Bootstrap from T5 core
Thanks for you positive feedback. I suggest the following now:
1) I will use git hub to create a new T5 Fork based on Thiagos
5.5.0-beta-1 and remove all bootstrap dependencies. As soon this
compiles we will have a T5.5 version looking like websites in the good
old early 80ies.
2) I will try to get our own (unfortunately internal) website up and
running again, including the latest BS3, means all BS code is located in
my client (it is anyway, because we use a newer BS3).
3) Next I extract all BS3 related code to a new module, thus we have a
plain T5.5 without BS, a T5-BS3-extension and a sample APP using the BS3
css classes / col definitions in TML code -> everything is like before,
existing code should still run without modifications.
4) I invite you to discuss the implementation details how we can best
make use of bootstrap related features without tight coupling so we can
basically change between BS3 and BS4. This means we need some way to
handle BS related differences like new / missing BS classes (for example
panel) and we have to support the different grid definitions aso. One
way (for example) might be T5 components to wrap most of the BS classes
and each extension lib will take care of the particular BS details. At
the very end our TML code never sees BS css classes at all, well at
least for the "most common" things. We can start this discussion right
now, because this is the tough part to my opinion. I would like to hear
/ read all your ideas.
5) We / I create a mini App using the new T5-BSx extensions do
demonstrate the use of the new BSx handling, we need it for testing /
discussing anyway (see 4)
We move over our disussion to github to avoid polluting the mailing list.
Ok?
Jens
Am 14.02.19 um 14:07 schrieb Bob Harner:
I agree that Tapestry shouldn't be so tightly coupled to a specific CSS
framework.
For context and some alternative ideas, see this prior discussion of the
same topic:
https://tapestry.markmail.org/search/?q=What+happens+when+Boootstrap+4+is+released%3F
On Thu, Feb 14, 2019, 4:52 AM Ben Weidig
Hi Jens,
I like the idea of decoupling the core and Bootstrap to make it easier to
use other versions.
Maybe the components should be updated to BS4 for T5.5, with a legacy
fallback or a component swap (can't remember the service doing it, we have
our own implementation, it's doing an advice on
ComponentClassResolver#resolveComponentTypeToClassName or
ComponentInstantiatorSource#getInstantiator).
For 5.4 we've developed an internal solution for using different BS
versions, here are some specifics.
We have multi-tenant-apps with different BS versions (so far up to 3), so
we needed a flexible solution that supports the internal BS and other
versions dynamically.
To make it even more flexible we've added SASS-support and compile
Bootstrap from the source files, with the possibility to add files
beforehand to the compilation step with custom variables etc.
The layout component has an annotation that triggers
a ComponentClassTransformWorker2 attaching a JavaScriptStack containing the
BS version decided by a contributable strategy pipeline.
JavaScript modules were the biggest problems, we started with replacing the
internal modules, but ended up adding additional modules instead. This
worked fine after getting all the dependencies right, but every BS version
might break it again, so we're now using the bundled version of BS JS.
We think this could all be cleaned up nicely if the internal BS wouldn't be
as integrated as it is right now.
Eventually we will release it as open-source, but having an integration
into Tapestry (as a new tapestry-*) would be even nicer :-)
Best regards
Ben
On Thu, Feb 14, 2019 at 10:14 AM Jens Breitenstein
wrote:
Hi Tapestry guys!
I want to hear/read your opinion about getting rid of the Bootstrap
Library from T5 core.
I would like to move all BS related code (css/js) to a seperate module
like "tapestry-bootstrap3" and decouple the hardcoded BS from T5.
Furthermore I would like to see a second module "tapestry-bootstrap4"
which uses BS4.
From the sources I see direct dependencies are less than expected. Some
tml's use it (I just ignore the internal T5 pages for now):
AjaxFormLoop.tml
class="btn btn-default btn-sm"
BeanEditForm.tml
class="btn-toolbar"
class="btn-group"
class="btn btn-primary"
DevTool.tml
class="dropdown-menu"
class="dropdown-header"
ExceptionDisplay.tml
class="well"
class="pull-right"
class="checkbox"// ?
Palette.tml
class="btn-group-vertical"
and some JAVA references like:
JavaScriptModule.java
configuration.add("bootstrap/ ...")
bundledModules=...
Do you think it's worths looking into it, digging deeper?
Any pitfalls I should consider?
Anyone interested to discuss it?
Jens
-
