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 <abang...@gmail.com> 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 <mailingl...@j-b-s.de> > 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 <b...@netzgut.net wrote: > > > > > >> 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" > > >>> <t:glyphicon name="plus-sign"/> > > >>> > > >>> BeanEditForm.tml > > >>> class="btn-toolbar" > > >>> class="btn-group" > > >>> class="btn btn-primary" > > >>> > > >>> DevTool.tml > > >>> <t:glyphicon name="cog"/> > > >>> 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 > > > > > > -- > http://www.mreunionlabs.net/ <http://www.mreunion-labs.net/> > twitter : @mreunionlabs @abangkis > page : https://plus.google.com/104168782385184990771 >
