Re: Open Discussion: remove Bootstrap from T5 core
Hello, everyone!
I know this thread is a bit old already, but Tapestry 5.5.0 can be used
without Bootstrap at all: https://tapestry.apache.org/release-notes-550.html
, https://tapestry.apache.org/css.html, @ImportModule(NoBootstrapModule.class).
In addition, there's a number of configuration symbols controlling which
CSS classes are output by the components which use Bootstrap ones by
default but can be overriden. If there's some CSS class still hardcoded,
please let us know.
On Thu, Feb 14, 2019 at 7: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
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Thiago
Re: Open Discussion: remove Bootstrap from T5 core
Hi David,
we've used @extend with SASS in our projects and ended up not using it a
lot due to its drawbacks, instead we use Bootstraps mixins more directly.
I haven't read the article in its entirety, but here are my thoughts:
For decoupling the components it might be possible to wrap the needed CSS
in placeholder selectors and aggregate them it in custom shared classes and
load only what needed. But if the components don't use the Bootstrap
classes directly we would need to change 2 classes if we like to change
behavior (e.g. .form-control and .t5-form-control).
And this doesn't deal with changed HTML-structure of Bootstrap components
between version. We needed to adapt our TML multiple times between
Bootstrap 4.0.0 beta and 4.1.2 and 4.2.1 (especially custom controls stuff).
Separated JARs or component swaps might be the better or at least more
maintainable option IMO.
Nevertheless the direct integration of SASS-support would be great. As
written before we added it ourselves with the help of
https://github.com/bit3/jsass so we can build Bootsrap from its SASS-source
instead of using the CSS-only version, and we can add some SASS beforehand
to set the
https://github.com/twbs/bootstrap/blob/master/scss/_variables.scss before
compiling Bootstrap to customize it (thanks to !default).
Works without any major issues in our projects.
Ben
On Thu, Feb 21, 2019 at 4:24 AM David Taylor
wrote:
> Anyone have experience working with the @extend directive in CSS
> preprocessors?
>
> I came across a post that advocates decoupling HTML markup from
> bootstrap classes by using @extend. I don't particularly agree with many
> of the points the author makes, but the technique is intriguing and
> might be something that can applied to Tapestry since we support Less.
> Here is the link to the article.
>
>
> https://hackernoon.com/the-backendification-of-frontend-development-62f218a773d4
>
> The interesting bit is titled "Dealing with CSS Frameworks" and contains
> the following example:
>
> %our-warning-button {
> @extend .btn;
> @extend .btn-warning;
> }
> .empty-shopping-cart-button {
>@extend %our-warning-button;
> }
>
> Searching the web a bit I came across another article that gets into
> this in more detail. The article's title is a bit misleading since it
> actually advocates the @extend technique and offer somes advice on best
> practices.
>
> https://webinista.com/updates/dont-use-extend-sass/
>
> David
>
> emailsig On 2/19/2019 6:03 AM, Chris Poulsen wrote:
> > Hi
> >
> > I think working on making the framework "core" more css agnostic seems
> like
> > a good direction, allowing things to move forward without having to try
> and
> > pick (and maintain) the correct bootstrap version (or other css framework
> > version/flavor). There is a pretty good chance that whatever is selected,
> > will not fit the requirements of everybody anyway.
> >
> > It is a while back, but was the tapestry bootstrap integration not
> > initially handled "externally" by a markup renderer filter (I guess it
> > removed the tapestry default styling and added the bootstrap equivalent).
> > Maybe something similar could be used to apply styling (Tapestry-BS3,
> > Tapestry- BS4 or whatever) to the tapestry components, without having to
> > dream up new stuff. (Provided that the processing does not become a
> > significant performance bottle-neck).
> >
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
Re: Open Discussion: remove Bootstrap from T5 core
Anyone have experience working with the @extend directive in CSS
preprocessors?
I came across a post that advocates decoupling HTML markup from
bootstrap classes by using @extend. I don't particularly agree with many
of the points the author makes, but the technique is intriguing and
might be something that can applied to Tapestry since we support Less.
Here is the link to the article.
https://hackernoon.com/the-backendification-of-frontend-development-62f218a773d4
The interesting bit is titled "Dealing with CSS Frameworks" and contains
the following example:
%our-warning-button {
@extend .btn;
@extend .btn-warning;
}
.empty-shopping-cart-button {
@extend %our-warning-button;
}
Searching the web a bit I came across another article that gets into
this in more detail. The article's title is a bit misleading since it
actually advocates the @extend technique and offer somes advice on best
practices.
https://webinista.com/updates/dont-use-extend-sass/
David
emailsig On 2/19/2019 6:03 AM, Chris Poulsen wrote:
Hi
I think working on making the framework "core" more css agnostic seems like
a good direction, allowing things to move forward without having to try and
pick (and maintain) the correct bootstrap version (or other css framework
version/flavor). There is a pretty good chance that whatever is selected,
will not fit the requirements of everybody anyway.
It is a while back, but was the tapestry bootstrap integration not
initially handled "externally" by a markup renderer filter (I guess it
removed the tapestry default styling and added the bootstrap equivalent).
Maybe something similar could be used to apply styling (Tapestry-BS3,
Tapestry- BS4 or whatever) to the tapestry components, without having to
dream up new stuff. (Provided that the processing does not become a
significant performance bottle-neck).
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Re: Open Discussion: remove Bootstrap from T5 core
Hi I think working on making the framework "core" more css agnostic seems like a good direction, allowing things to move forward without having to try and pick (and maintain) the correct bootstrap version (or other css framework version/flavor). There is a pretty good chance that whatever is selected, will not fit the requirements of everybody anyway. It is a while back, but was the tapestry bootstrap integration not initially handled "externally" by a markup renderer filter (I guess it removed the tapestry default styling and added the bootstrap equivalent). Maybe something similar could be used to apply styling (Tapestry-BS3, Tapestry- BS4 or whatever) to the tapestry components, without having to dream up new stuff. (Provided that the processing does not become a significant performance bottle-neck). -- Chris On Tue, Feb 19, 2019 at 10:05 AM abangkis wrote: > Another 👍👍 up. > > Btw, could you share the link to the github repo here? Thanks. > > On Fri, Feb 15, 2019 at 7:03 PM Jens Breitenstein > wrote: > > > 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 inter
Re: Re: Open Discussion: remove Bootstrap from T5 core
Another 👍👍 up. Btw, could you share the link to the github repo here? Thanks. On Fri, Feb 15, 2019 at 7:03 PM Jens Breitenstein wrote: > 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 < > mailingl...@j-b-s.de> > >> 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" > >>>
Re: Re: Open Discussion: remove Bootstrap from T5 core
Thiago, Template overriding would only work for those Tapestry-supplied components that use templates, right? But most currently don't, which could be changed and is part of what I was suggesting here: https://markmail.org/message/m5g3icg3jsxi7nc5 On Mon, Feb 18, 2019, 2:04 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > I know it's not the most future-proven way of doing this, but couldn't a > simple solution would be to have a separate JAR which subclasses the > components using Bootstrap, do nothing but change the template and then > contribute the components to ComponentOverride? > > On Fri, Feb 15, 2019 at 10:03 AM Jens Breitenstein > wrote: > > > 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 < > > mailingl...@j-b-s.de
Re: Re: Open Discussion: remove Bootstrap from T5 core
I know it's not the most future-proven way of doing this, but couldn't a simple solution would be to have a separate JAR which subclasses the components using Bootstrap, do nothing but change the template and then contribute the components to ComponentOverride? On Fri, Feb 15, 2019 at 10:03 AM Jens Breitenstein wrote: > 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 < > mailingl...@j-b-s.de> > >> 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): > >>> > >>> AjaxFormLo
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
-
Re: Open Discussion: remove Bootstrap from T5 core
I completely agree. We would like to move to bootstrap 4 and improve our
integration with Kendo UI in the process.
We also need to upgrade bootstrap 3 to the latest version since there
have been issues that cause it to show up as a XSS risk on application
vulnerability scans. Just yesterday bootstrap 3.4.1 was released to
address CVE-2019-8331.
We would be happy to participate in the development and testing of this
feature. We are actively developing hybrid applications on Tapestry and
would be able to test and provide feedback.
On 2/14/2019 6:20 PM, JumpStart wrote:
I think it’s a fabulous idea. Two thumbs up.
On 14 Feb 2019, at 9:07 pm, Bob Harner wrote:
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
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Open Discussion: remove Bootstrap from T5 core
I think it’s a fabulous idea. Two thumbs up.
> On 14 Feb 2019, at 9:07 pm, Bob Harner wrote:
>
> 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
>>>
>>>
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Open Discussion: remove Bootstrap from T5 core
Hi Jens,
I am interested by your project.
Maybe we can discuss further but right now I am super busy. What’s your
strategy to injection css classes inside components ?
Best
Sent from my iPhone!
Numa Schmeder
> Le 14 févr. 2019 à 10:04, Jens Breitenstein a écrit :
>
> 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
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Open Discussion: remove Bootstrap from T5 core
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
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
> >
> >
>
Re: Open Discussion: remove Bootstrap from T5 core
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
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
