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 ad
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 you
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. > >
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
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 >>> wr
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/ ...") bundled
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 > >
Open Discussion: remove Bootstrap from T5 core
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: Discussion: make duplicate contributions to services with ordered configurations an error
In both cases I would expect a hard exception instead of a soft warning. There’s already enough magic going on in the background. Best, Rafael On October 27, 2017 3:57:59 PM Dmitry Gusevwrote: Hi Thiago, I would expect this to throw an exception on application start. I would also expected that `configuration.override` would fix this, although it's not that clear what should happen if you're overriding a contribution twice, say, in different modules. Can we order the overrides somehow? If so I'd expected the last override would win if ordered, if override isn't ordered anyhow -- should fail with an error due to ambiguity. Not sure if that's doable at the moment, so just theorising. On Fri, Oct 27, 2017 at 4:40 PM, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: Hello! I've just stumbled again at https://issues.apache.org/ jira/browse/TAP5-1305, which boiled down to Tapestry-IoC dropping a contribution to an ordered configuration if there's another contribution with the same id. I fixed it specifically for service decorators. For service configurations, it remained the same: the contribution is dropped with a warning in the log, but I think this is easy to overlook and can cause errors which are difficult to spot since you consider that all contributions. What do you think of making contributing two different values to an ordered configuration with the same id a show-stopping error? -- Thiago -- Dmitry Gusev AnjLab Team http://anjlab.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion: make duplicate contributions to services with ordered configurations an error
On Fri, Oct 27, 2017 at 11:57 AM, Dmitry Gusevwrote: > Hi Thiago, > Hello, Dmitry! > I would expect this to throw an exception on application start. > Thanks for your opinion! Even more for agreeing with me! :D > I would also expected that `configuration.override` would fix this, > It would. This scenario isn't two different contributions with the same id, but a proper override. > although it's not that clear what should happen if you're overriding a > You raise a good question. What Tapestry does, and it has been this way at least since the 5.1 days, is to throw an exception when a contribution is overridden twice. > contribution twice, say, in different modules. > That's a problem we had at our day job, which has some extra configuration layers beyond factory defaults and application defaults. The solution was to create and contribute more SymbolProvider instances. Tapestry 5.4 improves the situation a little bit by processing modules are processed in alphabetical order instead of a non-deterministic one, as 5.3.x and previous ones did. This prevents some issues which only happened when the modules were processed in a certain order, so they wouldn't happen every time.
Re: Discussion: make duplicate contributions to services with ordered configurations an error
Hi Thiago, I would expect this to throw an exception on application start. I would also expected that `configuration.override` would fix this, although it's not that clear what should happen if you're overriding a contribution twice, say, in different modules. Can we order the overrides somehow? If so I'd expected the last override would win if ordered, if override isn't ordered anyhow -- should fail with an error due to ambiguity. Not sure if that's doable at the moment, so just theorising. On Fri, Oct 27, 2017 at 4:40 PM, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Hello! > > I've just stumbled again at https://issues.apache.org/ > jira/browse/TAP5-1305, > which boiled down to Tapestry-IoC dropping a contribution to an ordered > configuration if there's another contribution with the same id. I fixed it > specifically for service decorators. For service configurations, it > remained the same: the contribution is dropped with a warning in the log, > but I think this is easy to overlook and can cause errors which are > difficult to spot since you consider that all contributions. > > What do you think of making contributing two different values to an ordered > configuration with the same id a show-stopping error? > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
Discussion: make duplicate contributions to services with ordered configurations an error
Hello! I've just stumbled again at https://issues.apache.org/jira/browse/TAP5-1305, which boiled down to Tapestry-IoC dropping a contribution to an ordered configuration if there's another contribution with the same id. I fixed it specifically for service decorators. For service configurations, it remained the same: the contribution is dropped with a warning in the log, but I think this is easy to overlook and can cause errors which are difficult to spot since you consider that all contributions. What do you think of making contributing two different values to an ordered configuration with the same id a show-stopping error? -- Thiago
Re: Discussion- the verdict
I started with tapestry 5.1.2 some months ago thanks to a book called Tapestry 5 from Alexander Kolesnikov. It was a bit hard to understand how to create sites with this framework and yes, i also noticed the lack of documentation but with each new release it went better. Each time i had a problem i just came to this board and it was solved very fast, the documentation has increased by a lot on the last months and its going better and better very fast. A Tapestry in Action book is on the way too and i think this framework is great. I near left tapestry because of that kind of comments on some forums but finally i decided not to and im very happy with my decision. Im starting to understand a lot of new things and the way Tapestry+Hibernate work is just great. Its very easy to create new modules and componentes even if they need new Hibernate Entities, add this component to your maven dependencies and its working and the new entities created and managed by Hibernate without aditional configuration making extensibility easier and fast. I think tapestry, with a bit more documentation will be a great framework and will make things easier and faster. Its hard to start? Yes... and i will try to help with simple tutorials from my own experiences since i was a totally newbie some months ago, but i think think in a short time, we will get our reward. We just need to show the people how easy it is and the potential it has. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Re-Discussion-the-verdict-tp3337928p3339859.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion- the verdict
Yes, it's a pity that someone might be put off using the framework because of vocal, and misinformed minority. There's really no substitute for trying something yourself... On Wed, 2011-01-12 at 09:50 -0200, Thiago H. de Paula Figueiredo wrote: On Wed, 12 Jan 2011 08:53:41 -0200, George Banus georgeba...@gmail.com wrote: Hi Guys, Hi! So, I'm sorry I have to say that I'm saving my time and effort in learning Tapestry for something else. This is my decision for now, though I might change it in 3 or 4 years time after I notice some stability and consistencies in Tapestry releases. Please check the stability and consistency of all releases since Tapestry 5.1, the first T5 stable release. And don't believe everything you read on in the Internet. ;) - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion- the verdict
Hi Guys, I gave up on Tapestry. This was based on the overwhelmingly negative comments I've been reading about Tapestry on the Internet. Outside of this forum, I see no positive message about Tapestry anywhere. And that makes me very suspicious about the viability of this framework, besides all the nice and charming messages I have heard from you guys in this thread. So, I'm sorry I have to say that I'm saving my time and effort in learning Tapestry for something else. This is my decision for now, though I might change it in 3 or 4 years time after I notice some stability and consistencies in Tapestry releases. Again, sorry for this news :-( Bye, George On Tue, Dec 21, 2010 at 11:48 AM, George Banus georgeba...@gmail.comwrote: Hi, I am a newbie to Tapestry and while googling to learn more about tapestry, I found this discussion going on at http://www.theserverside.com/news/thread.tss?thread_id=61537. Some of the comments look very disappointing. Is Tapestry really used for serious projects? George
Re: Discussion- the verdict
George that's your problem not ours .. And the title verdict indicates that you have som legal authority ... I think we T5:ers have a competitive advantage and really see no need for spreading the light ... :-) T5 - Code less - Deliver more One could add Gossip less and shut down TSS Gunnar Eketrapp 2011/1/12 George Banus georgeba...@gmail.com Hi Guys, I gave up on Tapestry. This was based on the overwhelmingly negative comments I've been reading about Tapestry on the Internet. Outside of this forum, I see no positive message about Tapestry anywhere. And that makes me very suspicious about the viability of this framework, besides all the nice and charming messages I have heard from you guys in this thread. So, I'm sorry I have to say that I'm saving my time and effort in learning Tapestry for something else. This is my decision for now, though I might change it in 3 or 4 years time after I notice some stability and consistencies in Tapestry releases. Again, sorry for this news :-( Bye, George On Tue, Dec 21, 2010 at 11:48 AM, George Banus georgeba...@gmail.com wrote: Hi, I am a newbie to Tapestry and while googling to learn more about tapestry, I found this discussion going on at http://www.theserverside.com/news/thread.tss?thread_id=61537. Some of the comments look very disappointing. Is Tapestry really used for serious projects? George -- [Hem: 08-715 59 57, Mobil: 0708-52 62 90] Allévägen 2A, 132 42 Saltsjö-Boo
Re: Discussion- the verdict
George, we wish you a nice journey with regards Sven Homburg Founder of the Chenille Kit Project http://chenillekit.codehaus.org 2011/1/12 George Banus georgeba...@gmail.com: Hi Guys, I gave up on Tapestry. This was based on the overwhelmingly negative comments I've been reading about Tapestry on the Internet. Outside of this forum, I see no positive message about Tapestry anywhere. And that makes me very suspicious about the viability of this framework, besides all the nice and charming messages I have heard from you guys in this thread. So, I'm sorry I have to say that I'm saving my time and effort in learning Tapestry for something else. This is my decision for now, though I might change it in 3 or 4 years time after I notice some stability and consistencies in Tapestry releases. Again, sorry for this news :-( Bye, George On Tue, Dec 21, 2010 at 11:48 AM, George Banus georgeba...@gmail.comwrote: Hi, I am a newbie to Tapestry and while googling to learn more about tapestry, I found this discussion going on at http://www.theserverside.com/news/thread.tss?thread_id=61537. Some of the comments look very disappointing. Is Tapestry really used for serious projects? George - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion- the verdict
On Wed, 12 Jan 2011 08:53:41 -0200, George Banus georgeba...@gmail.com wrote: Hi Guys, Hi! So, I'm sorry I have to say that I'm saving my time and effort in learning Tapestry for something else. This is my decision for now, though I might change it in 3 or 4 years time after I notice some stability and consistencies in Tapestry releases. Please check the stability and consistency of all releases since Tapestry 5.1, the first T5 stable release. And don't believe everything you read on in the Internet. ;) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion- the verdict
Thiago, don't waste your time. Most probably the guy is yet another troll. He wrote 2 messages to the list: both about the TSS thread. On Wed, Jan 12, 2011 at 12:50 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: On Wed, 12 Jan 2011 08:53:41 -0200, George Banus georgeba...@gmail.com wrote: Hi Guys, Hi! So, I'm sorry I have to say that I'm saving my time and effort in learning Tapestry for something else. This is my decision for now, though I might change it in 3 or 4 years time after I notice some stability and consistencies in Tapestry releases. Please check the stability and consistency of all releases since Tapestry 5.1, the first T5 stable release. And don't believe everything you read on in the Internet. ;) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Best regards, Igor Drobiazko http://tapestry5.de
Re: Discussion- the verdict
Hi Igor We should answer these threads as these threads come up in search engines when some newbie is searching tapestry related information. It is threads like these which prevented me from considering Tapestry in my projects for so long. regards Taha On Wed, Jan 12, 2011 at 6:08 PM, Igor Drobiazko igor.drobia...@gmail.comwrote: Thiago, don't waste your time. Most probably the guy is yet another troll. He wrote 2 messages to the list: both about the TSS thread. On Wed, Jan 12, 2011 at 12:50 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: On Wed, 12 Jan 2011 08:53:41 -0200, George Banus georgeba...@gmail.com wrote: Hi Guys, Hi! So, I'm sorry I have to say that I'm saving my time and effort in learning Tapestry for something else. This is my decision for now, though I might change it in 3 or 4 years time after I notice some stability and consistencies in Tapestry releases. Please check the stability and consistency of all releases since Tapestry 5.1, the first T5 stable release. And don't believe everything you read on in the Internet. ;) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Best regards, Igor Drobiazko http://tapestry5.de
Re: Discussion
My company uses T5 for most of its software modules. We have more than 100 000 paying custumers. Works great and is great fun! On Wed, Dec 22, 2010 at 7:18 AM, Chuck Kring cjkr...@pacbell.net wrote: For what it's worth, Tapestry provides an embedded user interface for a medical device. We received FDA 510k clearance last fall and are working on the final details before our 1.0 release. This is deployed on a Linux appliance and mostly consists of Jetty, Tapestry, HSQLDB, Chenillekit, Spring-tapestry-security, JFreechart and JasperReports.Every instance of this product will provide services for all of the staff in a nursing home as well as collect data from every bed. There are not a lot of users per facility, but the user interface has a number of Ajax-enabled dashboards that have to stay alive, unattended, 7/24. I hope this qualifies as a 'serious project'. We've found Tapestry to be very reliable and once you get up the learning curve it is a very effective development environment. Personally I don't care what Howard looks like because his code looks great Chuck Kring www.wirelessmedcare.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Discussion
Hi, I am a newbie to Tapestry and while googling to learn more about tapestry, I found this discussion going on at http://www.theserverside.com/news/thread.tss?thread_id=61537. Some of the comments look very disappointing. Is Tapestry really used for serious projects? George
Re: Discussion
Well there's one person there who had negative comments. At the end of the day different people will prefer different frameworks - perhaps some aspect of a framework is more suited to particular project requirements, or maybe more generally suits a person's way of thinking or code style. For me I started out using Wicket and then was introduced to Tapestry 5 - and have not looked back. The dev cycle is much faster and it's much less verbose. The mailing list is extremely active with plenty of very experienced users contributing daily. And yes Tapestry is powering many enterprise/serious projects. It's far from complete, but some are listed here: http://wiki.apache.org/tapestry/PoweredByTapestry And as for documentation, Howard et al have done a great job pulling together updated docs. You can find them here: http://tapestry.apache.org/ The problem I think Tapestry has had is one with PR. I think a few people got disillusioned with backwards incompatability between major versions and moved elsewhere. However I know Howard and the Committers are doing everything they can to address this. That's my 2 cents; I'm sure others will be able to give you a more compelling/detailed justification for Tapestry. Richard. On Tue, 2010-12-21 at 11:48 +0100, George Banus wrote: Hi, I am a newbie to Tapestry and while googling to learn more about tapestry, I found this discussion going on at http://www.theserverside.com/news/thread.tss?thread_id=61537. Some of the comments look very disappointing. Is Tapestry really used for serious projects? George - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: Discussion
Some people just have an enormous chip on their shoulder and love to shout about it. There are some pretty serious projects out there using Tapestry, if I'm not mistaken. I don't see why someone wouldn't have it on their short-list of choices if starting a project. I think the only serious point these denouncers have is the lack of documentation - but even that has been addressed. c. -Original Message- From: George Banus [mailto:georgeba...@gmail.com] Sent: 21 December 2010 10:48 To: users@tapestry.apache.org Subject: Discussion Hi, I am a newbie to Tapestry and while googling to learn more about tapestry, I found this discussion going on at http://www.theserverside.com/news/thread.tss?thread_id=61537. Some of the comments look very disappointing. Is Tapestry really used for serious projects? George - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
On 21.12.2010 11:48, George Banus wrote: Is Tapestry really used for serious projects? We use Tapestry to build the core of our student information system. Term enrollments, course enrollments, grades, exams, class schedules. Having in mind that the students are studying computer science - and that some have already tried to break in in the past, and some probably will try in the future - it is indeed a serious project. smime.p7s Description: S/MIME Cryptographic Signature
Re: Discussion
On Tue, 21 Dec 2010 08:48:23 -0200, George Banus georgeba...@gmail.com wrote: Hi, Hi! I am a newbie to Tapestry and while googling to learn more about tapestry, I found this discussion going on at http://www.theserverside.com/news/thread.tss?thread_id=61537. Some of the comments look very disappointing. The article is trolling Tapestry. Jan de Jonge, one of the commenters, is a long-known Tapestry troll. Is Tapestry really used for serious projects? Yes. See the bottom of http://tapestry.apache.org/ to see some high profile sites using Tapestry, specially SeeSaw (something like the Hulu counterpart in the UK) and OED, the most respected English language dictionary. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
We run http://www.yanomo.com on tapestry 5. Features business critical project management and invoicing. Sounds serious enough to me ;-) I have also worked on a project using tap5 on clustered servers handling millions of requests a day. Having tried numurous frameworks I stuck with Tapetsry because it so bloody elegant. Works out of the box but allows customisation of almost everything if so required. Cheers, Joost On 21/12/10 12:18 PM, Vangel V. Ajanovski wrote: On 21.12.2010 11:48, George Banus wrote: Is Tapestry really used for serious projects? We use Tapestry to build the core of our student information system. Term enrollments, course enrollments, grades, exams, class schedules. Having in mind that the students are studying computer science - and that some have already tried to break in in the past, and some probably will try in the future - it is indeed a serious project. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
I have problems taking someone seriously who bases his argumentation on the looks of one of the developers and on exaggerated (indicator of bad reasoning) vague claims (bad reasoning) of many (bad reasoning, come up with better statistics) experiences. I would rather see compelling arguments against Tapestry that we could counter by improving the product, than criticism that would only be resolved by buying Howard a new haircut, which really wouldn't improve his coding or his vision of Tapestry. Op 21-12-2010 11:48, George Banus schreef: Hi, I am a newbie to Tapestry and while googling to learn more about tapestry, I found this discussion going on at http://www.theserverside.com/news/thread.tss?thread_id=61537. Some of the comments look very disappointing. Is Tapestry really used for serious projects? George - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
AW: Discussion
I agree with Tom. I think the linked comment thread is more like what you would expect from kiddy console flame war. If you don't like something why put effort into writing about how you don't like it? I would never get anything done ... If someone was seriously concerned about people sinking time and effort into learning a failed framework surely they would provide some actual arguments. I'm using tapestry for an intranet app with a few hundred users so it wouldn't count as important to some. It is important to me though, because I am responsible and want to deliever a good application. I have doubted my descision to use T5 sometimes (usually not because of technical issues) and other times I've felt almost estatic about it (for example when I successfully contributed a custom block to the beanedit component). About every year or so I do the web-framework round, trying to find out what's new etc and when this current project came along T5 was the only one I found worthy of spending any time with because it respects the time I spend. Most other frameworks don't work for me because I will not write any XML (beyond web.xml :) and I will not put up with having to expressing the same thing three slightly different ways. Kind Regards, Wulf -Ursprüngliche Nachricht- Von: Tom van Dijk [mailto:t...@tvandijk.nl] Gesendet: Dienstag, 21. Dezember 2010 13:06 An: users@tapestry.apache.org Betreff: Re: Discussion I have problems taking someone seriously who bases his argumentation on the looks of one of the developers and on exaggerated (indicator of bad reasoning) vague claims (bad reasoning) of many (bad reasoning, come up with better statistics) experiences. I would rather see compelling arguments against Tapestry that we could counter by improving the product, than criticism that would only be resolved by buying Howard a new haircut, which really wouldn't improve his coding or his vision of Tapestry. Op 21-12-2010 11:48, George Banus schreef: Hi, I am a newbie to Tapestry and while googling to learn more about tapestry, I found this discussion going on at http://www.theserverside.com/news/thread.tss?thread_id=61537. Some of the comments look very disappointing. Is Tapestry really used for serious projects? George - 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: Discussion
Is Tapestry really used for serious projects? Without trying to sound too aloof or flippant, the answer is: Yes. Not all of us can advertise the projects we work on, but T5 is definitely used for serious projects. mrg - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
I am using Tapestry on a project that manages humanitarian aid delivery, and I think it's serious enough. Not only is Tapestry used for serious projects, it's also for serious developers. Tapestry does come with a steep learning curve, and it requires you to unlearn many old ways of doing things. If you are serious and committed, you will be rewarded greatly in the end. Benny On Tue, Dec 21, 2010 at 9:58 AM, Michael Gentry mgen...@masslight.netwrote: Is Tapestry really used for serious projects? Without trying to sound too aloof or flippant, the answer is: Yes. Not all of us can advertise the projects we work on, but T5 is definitely used for serious projects. mrg - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
For what it's worth, Tapestry provides an embedded user interface for a medical device. We received FDA 510k clearance last fall and are working on the final details before our 1.0 release. This is deployed on a Linux appliance and mostly consists of Jetty, Tapestry, HSQLDB, Chenillekit, Spring-tapestry-security, JFreechart and JasperReports.Every instance of this product will provide services for all of the staff in a nursing home as well as collect data from every bed. There are not a lot of users per facility, but the user interface has a number of Ajax-enabled dashboards that have to stay alive, unattended, 7/24. I hope this qualifies as a 'serious project'. We've found Tapestry to be very reliable and once you get up the learning curve it is a very effective development environment. Personally I don't care what Howard looks like because his code looks great Chuck Kring www.wirelessmedcare.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: DISCUSSION: Time zones and date selection
Since our apps deals with sports team schedules, timezones are important for us. That's why I kept trying to suggest timezone support, whenever you discussed locale support. But your main question is how to determine a client's timezone. There is no http-header way to get it, and a Javascript timezone detector is the only thing I could come up with. Even with Javascript timezone detection, you will not know a user's timezone on their first request, only after the timezone detector executes, calls back to the server, and a user's httpsession has been updated with their timezone. Even if after you're OK with that, Javascript only gives you access to an offset for a particular date, but not the actual timezone Id. To get the timezone Id you have to take some offset samples for a few dates, and back track those samples against the timezone database in Java. What I did, was to take a few date samples ( jan, jun, today, two weeks from today ), and generate the offsets for those dates on the client-side, then compare those values against all known timezones on the server-side. That will give you a short list of possible timezones that will all work for the user. Then I just store that against the user (httpSesstion), much as you would store the user's Locale - through putting timezoneid in url is not an option. If you're interested, what's the best way to give you the few files that would get you started? attach to a bug? - TimeZoneLookup.java - service, does the timezone database lookup, versus date offset samples - components/common/TimeZoneDetector.java - components/common/TimeZoneDetector.js - component that executes javascript to get date offset samples, and calls back to server for capturing - doesn't render if timezone has been detected already - we have our layout include timezone detector, so all pages include it - pages/common/TimeZoneDetector.java - javascript calls back independent page (not component action) - because i don't want to deal with unnecessary page activation of pages containing the Detector On 8/7/10 9:10 AM, Howard Lewis Ship wrote: This is something that's been nagging me. Although there's a bunch of good options for selecting a date (or date/time) as JavaScript components bult into Tapestry, or available elsewhere ... none of them address the issue of the client and the server operating in different time zones. At the very least, these components probably should include a time zone drop down list (or other means of selection). I haven't been able to find a sure-fire way of determing the user's time zone from the HttpRequest. I'm curious what kinds of solutions the community have used to address this issue. It would be nice to come up with a true solution for Tapestry 5.3. One option is a bit of JavaScript that reports the client's time zone (or just time) to the server so that the server can identify their time zone automatically. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: DISCUSSION: Time zones and date selection
I didn't use one, but I believe such service exists that resolves client timezone by client IP. Client IP - Location - TimeZone. And this all may be resolved in very first request. On Thu, Aug 19, 2010 at 10:43, Fernando Padilla f...@alum.mit.edu wrote: Since our apps deals with sports team schedules, timezones are important for us. That's why I kept trying to suggest timezone support, whenever you discussed locale support. But your main question is how to determine a client's timezone. There is no http-header way to get it, and a Javascript timezone detector is the only thing I could come up with. Even with Javascript timezone detection, you will not know a user's timezone on their first request, only after the timezone detector executes, calls back to the server, and a user's httpsession has been updated with their timezone. Even if after you're OK with that, Javascript only gives you access to an offset for a particular date, but not the actual timezone Id. To get the timezone Id you have to take some offset samples for a few dates, and back track those samples against the timezone database in Java. What I did, was to take a few date samples ( jan, jun, today, two weeks from today ), and generate the offsets for those dates on the client-side, then compare those values against all known timezones on the server-side. That will give you a short list of possible timezones that will all work for the user. Then I just store that against the user (httpSesstion), much as you would store the user's Locale - through putting timezoneid in url is not an option. If you're interested, what's the best way to give you the few files that would get you started? attach to a bug? - TimeZoneLookup.java - service, does the timezone database lookup, versus date offset samples - components/common/TimeZoneDetector.java - components/common/TimeZoneDetector.js - component that executes javascript to get date offset samples, and calls back to server for capturing - doesn't render if timezone has been detected already - we have our layout include timezone detector, so all pages include it - pages/common/TimeZoneDetector.java - javascript calls back independent page (not component action) - because i don't want to deal with unnecessary page activation of pages containing the Detector On 8/7/10 9:10 AM, Howard Lewis Ship wrote: This is something that's been nagging me. Although there's a bunch of good options for selecting a date (or date/time) as JavaScript components bult into Tapestry, or available elsewhere ... none of them address the issue of the client and the server operating in different time zones. At the very least, these components probably should include a time zone drop down list (or other means of selection). I haven't been able to find a sure-fire way of determing the user's time zone from the HttpRequest. I'm curious what kinds of solutions the community have used to address this issue. It would be nice to come up with a true solution for Tapestry 5.3. One option is a bit of JavaScript that reports the client's time zone (or just time) to the server so that the server can identify their time zone automatically. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: DISCUSSION: Time zones and date selection
In addition to my previous message: http://stackoverflow.com/questions/41504/timezone-lookup-from-latitude-longitude I will probably use this approach to determine initial client timezone since I'm already use URL/IP to location functionality there: http://github.com/dmitrygusev/ping-service/blob/master/ping-service/src/dmitrygusev/ping/services/IPUtils.java (FYI this class uses http://ip-whois.net to resolve locations.) In current implementation I'm using UTC time by default in ping-service (GAE's default timezone), but user may specify its timezone in profile. On Thu, Aug 19, 2010 at 12:36, Dmitry Gusev dmitry.gu...@gmail.com wrote: I didn't use one, but I believe such service exists that resolves client timezone by client IP. Client IP - Location - TimeZone. And this all may be resolved in very first request. On Thu, Aug 19, 2010 at 10:43, Fernando Padilla f...@alum.mit.edu wrote: Since our apps deals with sports team schedules, timezones are important for us. That's why I kept trying to suggest timezone support, whenever you discussed locale support. But your main question is how to determine a client's timezone. There is no http-header way to get it, and a Javascript timezone detector is the only thing I could come up with. Even with Javascript timezone detection, you will not know a user's timezone on their first request, only after the timezone detector executes, calls back to the server, and a user's httpsession has been updated with their timezone. Even if after you're OK with that, Javascript only gives you access to an offset for a particular date, but not the actual timezone Id. To get the timezone Id you have to take some offset samples for a few dates, and back track those samples against the timezone database in Java. What I did, was to take a few date samples ( jan, jun, today, two weeks from today ), and generate the offsets for those dates on the client-side, then compare those values against all known timezones on the server-side. That will give you a short list of possible timezones that will all work for the user. Then I just store that against the user (httpSesstion), much as you would store the user's Locale - through putting timezoneid in url is not an option. If you're interested, what's the best way to give you the few files that would get you started? attach to a bug? - TimeZoneLookup.java - service, does the timezone database lookup, versus date offset samples - components/common/TimeZoneDetector.java - components/common/TimeZoneDetector.js - component that executes javascript to get date offset samples, and calls back to server for capturing - doesn't render if timezone has been detected already - we have our layout include timezone detector, so all pages include it - pages/common/TimeZoneDetector.java - javascript calls back independent page (not component action) - because i don't want to deal with unnecessary page activation of pages containing the Detector On 8/7/10 9:10 AM, Howard Lewis Ship wrote: This is something that's been nagging me. Although there's a bunch of good options for selecting a date (or date/time) as JavaScript components bult into Tapestry, or available elsewhere ... none of them address the issue of the client and the server operating in different time zones. At the very least, these components probably should include a time zone drop down list (or other means of selection). I haven't been able to find a sure-fire way of determing the user's time zone from the HttpRequest. I'm curious what kinds of solutions the community have used to address this issue. It would be nice to come up with a true solution for Tapestry 5.3. One option is a bit of JavaScript that reports the client's time zone (or just time) to the server so that the server can identify their time zone automatically. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: DISCUSSION: Time zones and date selection
Here's the service description: http://www.geonames.org/export/web-services.html#timezone http://www.geonames.org/export/web-services.html#timezoneAnd JSON example for ping-service (XML is service also there): http://ws.geonames.org/timezoneJSON?lat=37.41lng=-122.05 {time:2010-08-19 01:56,countryName:United States,sunset:2010-08-19 19:55,rawOffset:-8,dstOffset:-7,countryCode:US,gmtOffset:-8,lng:-122.05,sunrise:2010-08-19 06:27,timezoneId:America/Los_Angeles,lat:37.41} On Thu, Aug 19, 2010 at 12:49, Dmitry Gusev dmitry.gu...@gmail.com wrote: In addition to my previous message: http://stackoverflow.com/questions/41504/timezone-lookup-from-latitude-longitude I will probably use this approach to determine initial client timezone since I'm already use URL/IP to location functionality there: http://github.com/dmitrygusev/ping-service/blob/master/ping-service/src/dmitrygusev/ping/services/IPUtils.java (FYI this class uses http://ip-whois.net to resolve locations.) In current implementation I'm using UTC time by default in ping-service (GAE's default timezone), but user may specify its timezone in profile. On Thu, Aug 19, 2010 at 12:36, Dmitry Gusev dmitry.gu...@gmail.comwrote: I didn't use one, but I believe such service exists that resolves client timezone by client IP. Client IP - Location - TimeZone. And this all may be resolved in very first request. On Thu, Aug 19, 2010 at 10:43, Fernando Padilla f...@alum.mit.eduwrote: Since our apps deals with sports team schedules, timezones are important for us. That's why I kept trying to suggest timezone support, whenever you discussed locale support. But your main question is how to determine a client's timezone. There is no http-header way to get it, and a Javascript timezone detector is the only thing I could come up with. Even with Javascript timezone detection, you will not know a user's timezone on their first request, only after the timezone detector executes, calls back to the server, and a user's httpsession has been updated with their timezone. Even if after you're OK with that, Javascript only gives you access to an offset for a particular date, but not the actual timezone Id. To get the timezone Id you have to take some offset samples for a few dates, and back track those samples against the timezone database in Java. What I did, was to take a few date samples ( jan, jun, today, two weeks from today ), and generate the offsets for those dates on the client-side, then compare those values against all known timezones on the server-side. That will give you a short list of possible timezones that will all work for the user. Then I just store that against the user (httpSesstion), much as you would store the user's Locale - through putting timezoneid in url is not an option. If you're interested, what's the best way to give you the few files that would get you started? attach to a bug? - TimeZoneLookup.java - service, does the timezone database lookup, versus date offset samples - components/common/TimeZoneDetector.java - components/common/TimeZoneDetector.js - component that executes javascript to get date offset samples, and calls back to server for capturing - doesn't render if timezone has been detected already - we have our layout include timezone detector, so all pages include it - pages/common/TimeZoneDetector.java - javascript calls back independent page (not component action) - because i don't want to deal with unnecessary page activation of pages containing the Detector On 8/7/10 9:10 AM, Howard Lewis Ship wrote: This is something that's been nagging me. Although there's a bunch of good options for selecting a date (or date/time) as JavaScript components bult into Tapestry, or available elsewhere ... none of them address the issue of the client and the server operating in different time zones. At the very least, these components probably should include a time zone drop down list (or other means of selection). I haven't been able to find a sure-fire way of determing the user's time zone from the HttpRequest. I'm curious what kinds of solutions the community have used to address this issue. It would be nice to come up with a true solution for Tapestry 5.3. One option is a bit of JavaScript that reports the client's time zone (or just time) to the server so that the server can identify their time zone automatically. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com -- Dmitry Gusev AnjLab Team http://anjlab.com -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: DISCUSSION: Time zones and date selection
Yeah, i guess each his own. Though the ip resolution way does seem cleaner in some ways, it does seem way more complicated in others.. and dependent on other services.. etc.. I guess we just realized that TimeZone Detector should be easily pluggable, to fit people's taste and requirements... :) On 8/19/10 1:36 AM, Dmitry Gusev wrote: I didn't use one, but I believe such service exists that resolves client timezone by client IP. Client IP - Location - TimeZone. And this all may be resolved in very first request. On Thu, Aug 19, 2010 at 10:43, Fernando Padillaf...@alum.mit.edu wrote: Since our apps deals with sports team schedules, timezones are important for us. That's why I kept trying to suggest timezone support, whenever you discussed locale support. But your main question is how to determine a client's timezone. There is no http-header way to get it, and a Javascript timezone detector is the only thing I could come up with. Even with Javascript timezone detection, you will not know a user's timezone on their first request, only after the timezone detector executes, calls back to the server, and a user's httpsession has been updated with their timezone. Even if after you're OK with that, Javascript only gives you access to an offset for a particular date, but not the actual timezone Id. To get the timezone Id you have to take some offset samples for a few dates, and back track those samples against the timezone database in Java. What I did, was to take a few date samples ( jan, jun, today, two weeks from today ), and generate the offsets for those dates on the client-side, then compare those values against all known timezones on the server-side. That will give you a short list of possible timezones that will all work for the user. Then I just store that against the user (httpSesstion), much as you would store the user's Locale - through putting timezoneid in url is not an option. If you're interested, what's the best way to give you the few files that would get you started? attach to a bug? - TimeZoneLookup.java - service, does the timezone database lookup, versus date offset samples - components/common/TimeZoneDetector.java - components/common/TimeZoneDetector.js - component that executes javascript to get date offset samples, and calls back to server for capturing - doesn't render if timezone has been detected already - we have our layout include timezone detector, so all pages include it - pages/common/TimeZoneDetector.java - javascript calls back independent page (not component action) - because i don't want to deal with unnecessary page activation of pages containing the Detector On 8/7/10 9:10 AM, Howard Lewis Ship wrote: This is something that's been nagging me. Although there's a bunch of good options for selecting a date (or date/time) as JavaScript components bult into Tapestry, or available elsewhere ... none of them address the issue of the client and the server operating in different time zones. At the very least, these components probably should include a time zone drop down list (or other means of selection). I haven't been able to find a sure-fire way of determing the user's time zone from the HttpRequest. I'm curious what kinds of solutions the community have used to address this issue. It would be nice to come up with a true solution for Tapestry 5.3. One option is a bit of JavaScript that reports the client's time zone (or just time) to the server so that the server can identify their time zone automatically. - 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: DISCUSSION: Time zones and date selection
One more thing, I've added Geonames to ping service to measure its performance and got the following statistics: Was made 47 requests (one for every 15 minutes) with average response time 750 ms. During this period I got some bad responses: {status:{message:the hourly limit of 3000 credits for the IP address 72.14.192.68 has been exceeded. Please throttle your requests or use the commercial service.,value:19}} Its availability percent (percent of expected responses) was 93.75% for the past 12 hours. So its probably not a good option to use Geonames in a cloud for free... but still an option. On Thu, Aug 19, 2010 at 19:56, Fernando Padilla f...@alum.mit.edu wrote: Yeah, i guess each his own. Though the ip resolution way does seem cleaner in some ways, it does seem way more complicated in others.. and dependent on other services.. etc.. I guess we just realized that TimeZone Detector should be easily pluggable, to fit people's taste and requirements... :) On 8/19/10 1:36 AM, Dmitry Gusev wrote: I didn't use one, but I believe such service exists that resolves client timezone by client IP. Client IP - Location - TimeZone. And this all may be resolved in very first request. On Thu, Aug 19, 2010 at 10:43, Fernando Padillaf...@alum.mit.edu wrote: Since our apps deals with sports team schedules, timezones are important for us. That's why I kept trying to suggest timezone support, whenever you discussed locale support. But your main question is how to determine a client's timezone. There is no http-header way to get it, and a Javascript timezone detector is the only thing I could come up with. Even with Javascript timezone detection, you will not know a user's timezone on their first request, only after the timezone detector executes, calls back to the server, and a user's httpsession has been updated with their timezone. Even if after you're OK with that, Javascript only gives you access to an offset for a particular date, but not the actual timezone Id. To get the timezone Id you have to take some offset samples for a few dates, and back track those samples against the timezone database in Java. What I did, was to take a few date samples ( jan, jun, today, two weeks from today ), and generate the offsets for those dates on the client-side, then compare those values against all known timezones on the server-side. That will give you a short list of possible timezones that will all work for the user. Then I just store that against the user (httpSesstion), much as you would store the user's Locale - through putting timezoneid in url is not an option. If you're interested, what's the best way to give you the few files that would get you started? attach to a bug? - TimeZoneLookup.java - service, does the timezone database lookup, versus date offset samples - components/common/TimeZoneDetector.java - components/common/TimeZoneDetector.js - component that executes javascript to get date offset samples, and calls back to server for capturing - doesn't render if timezone has been detected already - we have our layout include timezone detector, so all pages include it - pages/common/TimeZoneDetector.java - javascript calls back independent page (not component action) - because i don't want to deal with unnecessary page activation of pages containing the Detector On 8/7/10 9:10 AM, Howard Lewis Ship wrote: This is something that's been nagging me. Although there's a bunch of good options for selecting a date (or date/time) as JavaScript components bult into Tapestry, or available elsewhere ... none of them address the issue of the client and the server operating in different time zones. At the very least, these components probably should include a time zone drop down list (or other means of selection). I haven't been able to find a sure-fire way of determing the user's time zone from the HttpRequest. I'm curious what kinds of solutions the community have used to address this issue. It would be nice to come up with a true solution for Tapestry 5.3. One option is a bit of JavaScript that reports the client's time zone (or just time) to the server so that the server can identify their time zone automatically. - 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 -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: DISCUSSION: Time zones and date selection
Hi, I do everything server side with the help of a custom TimeZoneAwareDatePicker wrapping your tapx datepicker. It takes a source (I store everything in UTC) and display timezone (the users timezone) to do the conversion. This suits me because I will almost always know my users timezone as they need to be logged in. In all my applications where I need to be timezone aware, I make sure to have my users specify it upfront and store it all server side. To help my users I assume the most logical tz through some util classes I build around http://icu-project.org/apiref/icu4j/. These util classes have methods like getBestMatchingTimeZone(Locale locale). Personally I wouldn't want to add a time zone drop down to a date picker as it would be too much in my opinion. Cheers, Joost On Sat, Aug 7, 2010 at 6:10 PM, Howard Lewis Ship hls...@gmail.com wrote: This is something that's been nagging me. Although there's a bunch of good options for selecting a date (or date/time) as JavaScript components bult into Tapestry, or available elsewhere ... none of them address the issue of the client and the server operating in different time zones. At the very least, these components probably should include a time zone drop down list (or other means of selection). I haven't been able to find a sure-fire way of determing the user's time zone from the HttpRequest. I'm curious what kinds of solutions the community have used to address this issue. It would be nice to come up with a true solution for Tapestry 5.3. One option is a bit of JavaScript that reports the client's time zone (or just time) to the server so that the server can identify their time zone automatically. -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
DISCUSSION: Time zones and date selection
This is something that's been nagging me. Although there's a bunch of good options for selecting a date (or date/time) as JavaScript components bult into Tapestry, or available elsewhere ... none of them address the issue of the client and the server operating in different time zones. At the very least, these components probably should include a time zone drop down list (or other means of selection). I haven't been able to find a sure-fire way of determing the user's time zone from the HttpRequest. I'm curious what kinds of solutions the community have used to address this issue. It would be nice to come up with a true solution for Tapestry 5.3. One option is a bit of JavaScript that reports the client's time zone (or just time) to the server so that the server can identify their time zone automatically. -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
Re: DISCUSSION: Time zones and date selection
Hi Just an add, related issue was reported there https://issues.apache.org/jira/browse/TAP5-841 2010/8/7 Howard Lewis Ship hls...@gmail.com This is something that's been nagging me. Although there's a bunch of good options for selecting a date (or date/time) as JavaScript components bult into Tapestry, or available elsewhere ... none of them address the issue of the client and the server operating in different time zones. At the very least, these components probably should include a time zone drop down list (or other means of selection). I haven't been able to find a sure-fire way of determing the user's time zone from the HttpRequest. I'm curious what kinds of solutions the community have used to address this issue. It would be nice to come up with a true solution for Tapestry 5.3. One option is a bit of JavaScript that reports the client's time zone (or just time) to the server so that the server can identify their time zone automatically. -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com -- Regards, Christophe Cordenier. Committer on Apache Tapestry 5 Co-creator of wooki @wookicentral.com
Re: Discussion
Em Thu, 24 Dec 2009 10:31:15 -0200, Alessandro Bottoni alexbott...@gmail.com escreveu: Regarding this topics, let me remind the ML people that there are at least two projects that tries to supply Tapestry 5 with the remaining components needed to build a full-stack framework (or something like that): Tynamo (formerly known as Trails) and AppFuse. T5 can be a simple framework but Tynamo and AppFuse are much more than this. I guess you can add the Ars Machina Project there, although the approach is different (several focused packages vs one single framework) and I didn't have time to write the documentation yet. I'm already using them in my projects: If you're adventurous enough, take a look at the sources: http://ars-machina.svn.sourceforge.net/viewvc/ars-machina/ :) Warning: the newer code of most projects are in branches, not the trunk. I think that what the newbie (like me) and the end-user/dev are expecting from T5+Tynamo is something like a Drupal on steroids: a empty CMS (coming from a Maven archetype) that can be easily configured I beg to differ. A web framework has a very different objective from a CMS. You can build a CMS with Tapestry, but T5, AFAIK, never had the goal of being one. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Il 26/12/2009 19:24, Thiago H. de Paula Figueiredo ha scritto: I think that what the newbie (like me) and the end-user/dev are expecting from T5+Tynamo is something like a Drupal on steroids: a empty CMS (coming from a Maven archetype) that can be easily configured I beg to differ. A web framework has a very different objective from a CMS. You can build a CMS with Tapestry, but T5, AFAIK, never had the goal of being one. Yes, of course. I said T5+Tynamo just to underline this detail. T5 alone cannot play this role. T5+Tynamo, on the other side, do have to offer this level of readiness. Thinking at T5 (alone) as the underlining technology of Tynamo (or of a general purpose CMS) can make easier to spot what is missing and what is wrong. After all, what the poor developer will have to build is something very similar to Tynamo (or to Drupal). CU -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ When future stopped to be a promise and started to be a threat? -- Street wall graffiti, Bologna, 1999 - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Il 23/12/2009 19:48, Thiago H. de Paula Figueiredo ha scritto: Em Wed, 23 Dec 2009 16:22:49 -0200, Piero Sartini I don't like it as well - but tapestry should provide an alternative. Maybe the question is if tapestry wants to be a full-stack framework or just deliver some building blocks. For being a full-stack framework, there is not enough functionality available. To just provide building blocks, it dictates too much (javascript library, markup, and so on). Of course this is just my feeling. I cannot speak for the project, but I think Tapestry tries to be a Web framework, not a full stack. At least not yet. ;) Regarding this topics, let me remind the ML people that there are at least two projects that tries to supply Tapestry 5 with the remaining components needed to build a full-stack framework (or something like that): Tynamo (formerly known as Trails) and AppFuse. T5 can be a simple framework but Tynamo and AppFuse are much more than this. Looking at T5 from this perspective, it looks very good. T5 should/could supply us with just the fundamental blocks and Tynamo/AppFuse could/should do the rest. Also, it should be much easier to manage the whole dev process in this way. I think that what the newbie (like me) and the end-user/dev are expecting from T5+Tynamo is something like a Drupal on steroids: a empty CMS (coming from a Maven archetype) that can be easily configured (like Drupal) and extended (Drupal is a pain to modify and extend, when used for big and complex projects). In other words, a empty system than can be used as a good starting point for a real-world (that is: quite complex) web application. Such a Maven archetype should supply all of the basic building blocks of a real-world application: - access control (Acegi/Spring security or something like that) - i18n/i10n and language switching - persistance (against MySQL, for example) - user registration - user administration - captcha? - e-mail verification (send/verify) - etc. To the end-user should remain the responsability to de/activate every single feature and to configure them. Such a system, being based on a well-engineered technology like T5, would be immensely easier to extend and modify than CMSs like Drupal and immensely more robust. As long as I can see, T5 and Tynamo are already evolving together in this way. It is just a matter of time to have such a Drupal-on-steroids archetype. As Piero said, at the moment T5 is probably enforcing some choice that could/should be left to the end-user/dev (javascript library, markup, etc.) but, as long as I can see, it should not be very hard to loosen such requisites in future releases. Dojo and JQuery can already be used together with T5 (cannot they?) and allowing the dev to use a different mark-up should be just a matter to accept a different XML namespace (a superset of the T5's). Am I wrong? JM2C -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ Perfection is finally attained not when there is no longer anything to add but when there is no longer anything to take away. -- Antoine de Saint-Exupéry - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Alfonso Quiroga wrote: ³Last, it would be good more components (ui components).² +1 , plus it really would be nice if it comes before the above javascript/prototype/jquery implementation/change: ³There's a plan not to switch from Prototype to jQuery. There's a plan to have JavaScript stacks, one implemented with Prototype, another with jQuery. No dates yet.² How much javascript are the developers here using? I prefer to use only when necessary (yeah, I¹m one that runs from it like from the devil :-)) Merry Christmas to everyone on the list.
Re: Discussion
Hi everybody, I think the discussion on TheServerSide actually is somewhat interesting, but not because of the unfortunate Tapestry vs. Wicket flame war. Let's have a look at the topic leading to that... - One part of Java EE 6 is CDI (JSR 299) - http://jcp.org/en/jsr/detail?id=299 - originally called Web beans. I think it was inspired by Gavin Kings Seam Framework. - The reference implementation for that seems to be something called Weld - http://docs.jboss.org/weld/reference/1.0.0/en-US/html/ - Weld has Wicket support build in, and the examples are given in Wicket (although the Java EE standard would be JSF 2) because Wicket is easier to learn than JSF (at least Gavin King says so in http://in.relation.to/Bloggers/HowToStartLearningJavaEE6, but I think many would agree with that). So the interesting (to me, at least) questions are: - How does CDI relate to Tapesty and Tapestry IOC? - Should / could Tapestry incorporate / conform to CDI somehow? - Should we try to add Tapestry support to Weld? - Or is Java EE 6 / CDI just not relevant to Tapestry? I haven't really looked at Web Beans resp. CDI yet, but from first site, it defines some context scopes (request, session, application, conversation) and some annotation based dependency injection. Both areas are already covered by Tapestry (although afaik there is no conversation scope (yet) in Tapestry). So are CDI and Tapestry mutually exclusive? Or should Tapestry be refactored to use standard CDI annotations, so it can claim to be a CDI / JSR 299 implementation? I would love to hear your opinions about that. Regards, Lutz -- altocon GmbH http://www.altocon.de/ Software Development, Consulting Hamburg, Germany - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Em Wed, 23 Dec 2009 06:25:14 -0200, Lutz Hühnken lh.tapestry.l...@googlemail.com escreveu: Hi everybody, Hi! So the interesting (to me, at least) questions are: - How does CDI relate to Tapesty and Tapestry IOC? - Should / could Tapestry incorporate / conform to CDI somehow? - Should we try to add Tapestry support to Weld? - Or is Java EE 6 / CDI just not relevant to Tapestry? There's a recent discussion about that in the dev mailing list. Everyone is invited. :) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Lutz, Having seen some discussions in the past about the history of Tapestry, I'm wondering what the status of Tapestry with CDI support will be. In other words, is it again going to result a new major release incompatible with previous versions? I think CDI in it's current form, if should be supported, would require some fundamental changes to the core of Tapestry's IoC that would definitely result in API break. At least the Spring guys also say so about their framework. I have an idea, may be a controversial one. I've seen much about Tapestry and think it's a nice Framework. But what I still don't understand is why it's not widely in use. It existed before Wicket but Wicket is far more popular. I don't think it's only because it's users are very vocal. There is also a saying that a good product sometimes sells itself. My proposition is why not let Tapestry and Wicket join hands, migrate some of the nice ideas to Wicket and lets try to go standardize Wicket as a JSR. Again, I know this is a controversial proposition that might result in some immature ones labeling and calling me names, as I've seen in the archives. On the other hand I know there are wise and intelligent ones in this community who would offer constructive arguments. It is these group of people that I'll consider serious. Gerald 2009/12/23 Lutz Hühnken lh.tapestry.l...@googlemail.com Hi everybody, I think the discussion on TheServerSide actually is somewhat interesting, but not because of the unfortunate Tapestry vs. Wicket flame war. Let's have a look at the topic leading to that... - One part of Java EE 6 is CDI (JSR 299) - http://jcp.org/en/jsr/detail?id=299 - originally called Web beans. I think it was inspired by Gavin Kings Seam Framework. - The reference implementation for that seems to be something called Weld - http://docs.jboss.org/weld/reference/1.0.0/en-US/html/ - Weld has Wicket support build in, and the examples are given in Wicket (although the Java EE standard would be JSF 2) because Wicket is easier to learn than JSF (at least Gavin King says so in http://in.relation.to/Bloggers/HowToStartLearningJavaEE6, but I think many would agree with that). So the interesting (to me, at least) questions are: - How does CDI relate to Tapesty and Tapestry IOC? - Should / could Tapestry incorporate / conform to CDI somehow? - Should we try to add Tapestry support to Weld? - Or is Java EE 6 / CDI just not relevant to Tapestry? I haven't really looked at Web Beans resp. CDI yet, but from first site, it defines some context scopes (request, session, application, conversation) and some annotation based dependency injection. Both areas are already covered by Tapestry (although afaik there is no conversation scope (yet) in Tapestry). So are CDI and Tapestry mutually exclusive? Or should Tapestry be refactored to use standard CDI annotations, so it can claim to be a CDI / JSR 299 implementation? I would love to hear your opinions about that. Regards, Lutz -- altocon GmbH http://www.altocon.de/ Software Development, Consulting Hamburg, Germany - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
There's a recent discussion about that in the dev mailing list. Everyone is invited. :) Thiago could you provide a link perhaps? -- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail. - Original Message - From: Gerald Bauer gtat...@gmail.com To: Tapestry users users@tapestry.apache.org Sent: Wednesday, 23 December, 2009 11:59:47 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Discussion Lutz, Having seen some discussions in the past about the history of Tapestry, I'm wondering what the status of Tapestry with CDI support will be. In other words, is it again going to result a new major release incompatible with previous versions? I think CDI in it's current form, if should be supported, would require some fundamental changes to the core of Tapestry's IoC that would definitely result in API break. At least the Spring guys also say so about their framework. I have an idea, may be a controversial one. I've seen much about Tapestry and think it's a nice Framework. But what I still don't understand is why it's not widely in use. It existed before Wicket but Wicket is far more popular. I don't think it's only because it's users are very vocal. There is also a saying that a good product sometimes sells itself. My proposition is why not let Tapestry and Wicket join hands, migrate some of the nice ideas to Wicket and lets try to go standardize Wicket as a JSR. Again, I know this is a controversial proposition that might result in some immature ones labeling and calling me names, as I've seen in the archives. On the other hand I know there are wise and intelligent ones in this community who would offer constructive arguments. It is these group of people that I'll consider serious. Gerald 2009/12/23 Lutz Hühnken lh.tapestry.l...@googlemail.com Hi everybody, I think the discussion on TheServerSide actually is somewhat interesting, but not because of the unfortunate Tapestry vs. Wicket flame war. Let's have a look at the topic leading to that... - One part of Java EE 6 is CDI (JSR 299) - http://jcp.org/en/jsr/detail?id=299 - originally called Web beans. I think it was inspired by Gavin Kings Seam Framework. - The reference implementation for that seems to be something called Weld - http://docs.jboss.org/weld/reference/1.0.0/en-US/html/ - Weld has Wicket support build in, and the examples are given in Wicket (although the Java EE standard would be JSF 2) because Wicket is easier to learn than JSF (at least Gavin King says so in http://in.relation.to/Bloggers/HowToStartLearningJavaEE6, but I think many would agree with that). So the interesting (to me, at least) questions are: - How does CDI relate to Tapesty and Tapestry IOC? - Should / could Tapestry incorporate / conform to CDI somehow? - Should we try to add Tapestry support to Weld? - Or is Java EE 6 / CDI just not relevant to Tapestry? I haven't really looked at Web Beans resp. CDI yet, but from first site, it defines some context scopes (request, session, application, conversation) and some annotation based dependency injection. Both areas are already covered by Tapestry (although afaik there is no conversation scope (yet) in Tapestry). So are CDI and Tapestry mutually exclusive? Or should Tapestry be refactored to use standard CDI annotations, so it can claim to be a CDI / JSR 299 implementation? I would love to hear your opinions about that. Regards, Lutz -- altocon GmbH http://www.altocon.de/ Software Development, Consulting Hamburg, Germany - 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: Discussion
Em Wed, 23 Dec 2009 07:59:47 -0200, Gerald Bauer gtat...@gmail.com escreveu: Lutz, Hi! Having seen some discussions in the past about the history of Tapestry, I'm wondering what the status of Tapestry with CDI support will be. In other words, is it again going to result a new major release incompatible with previous versions? I think CDI in it's current form, if should be supported, would require some fundamental changes to the core of Tapestry's IoC that would definitely result in API break. At least the Spring guys also say so about their framework. Tapestry-IoC's public API is very, very small, so I don't think an API break is necessary at all for CDI support. My classes are Tapestry-IoC services and they have no dependency on it. AFAIK, all it needs to implement CDI is to keep the current semantics and change to CDI's when CDI's @Inject annotation is found. My proposition is why not let Tapestry and Wicket join hands, migrate some of the nice ideas to Wicket and lets try to go standardize Wicket as a JSR. That wouldn't work. Wicket and Tapestry share many concepts, but the approach to implement them is radically different. I don't think another JSR concerning web frameworks would be accepted. I also think that JSRs work better for lower level issues (transaction management, object-relational mapping). Anyway, I love the idea of competition: we have many different Web frameworks with many different approaches, with many of them bringing some nice inovations that can be added to the others. Diversity is a very good thing. :) By the way, why don't we standardize Tapestry instead of Wicket? ;) Again, I know this is a controversial proposition that might result in some immature ones labeling and calling me names, as I've seen in the archives. We had some unbelievably annoying trolls in the past, almost all of them Wicket users, so there was a precedent here. If you're not a troll, welcome to the list. :) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Em Wed, 23 Dec 2009 08:21:23 -0200, Peter Stavrinides p.stavrini...@albourne.com escreveu: There's a recent discussion about that in the dev mailing list. Everyone is invited. :) Thiago could you provide a link perhaps? Yes! :) http://old.nabble.com/JSR-229%2C-JSR-330-and-other-integrations-to26857781.html -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Having seen some discussions in the past about the history of Tapestry, I'm wondering what the status of Tapestry with CDI support will be. In other words, is it again going to result a new major release incompatible with previous versions? I think CDI in it's current form, if should be supported, would require some fundamental changes to the core of Tapestry's IoC that would definitely result in API break. At least the Spring guys also say so about their framework. I am not sure if it is possible or not to integrate CDI without breaking backwards compatibility... but it is something we should find out. Spring guys are no reliable source, they want to sell their product and if I were them, I would fear CDI as well. I have an idea, may be a controversial one. I've seen much about Tapestry and think it's a nice Framework. But what I still don't understand is why it's not widely in use. It existed before Wicket but Wicket is far more popular. I don't think it's only because it's users are very vocal. There is also a saying that a good product sometimes sells itself. I've also thought about this, and my only conclusion is that Tapestry is too difficult to master. Especially when it comes to tapestry-ioc and getting productive with it. I am not talking about building the frontend and components.. this is easy and IMHO the thing where tapestry really shines. But there are way too less integrations - see my tapestry-jpa experiment for an example. It works, but it would need some love from some smarter people than me to get proper unit tests and some missing parts. If I look at Wicket or other frameworks there are lots and lots of integration modules for just everything. Why is that? My answer is because it is way easier to write them. My proposition is why not let Tapestry and Wicket join hands, migrate some of the nice ideas to Wicket and lets try to go standardize Wicket as a JSR. I am not sure I would like this. I've tried wicket in the past, and for me it is too verbose. I don't like the Swing-Approach and these inner classes everywhere. Tapestry's approach to the front-end programming is excellent, I don't want to trade this. But I would be perfectly fine trading the IoC container... Piero - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
-- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail. I've also thought about this, and my only conclusion is that Tapestry is too difficult to master. Especially when it comes to tapestry-ioc and getting productive with it. Only because of the lack of good docs and tutorials... its a pity though because it may appear daunting to begin with, but when you do learn it, it is so simple its sick. regards, Peter - Original Message - From: Piero Sartini li...@pierosartini.de To: Tapestry users users@tapestry.apache.org Sent: Wednesday, 23 December, 2009 12:28:35 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Discussion Having seen some discussions in the past about the history of Tapestry, I'm wondering what the status of Tapestry with CDI support will be. In other words, is it again going to result a new major release incompatible with previous versions? I think CDI in it's current form, if should be supported, would require some fundamental changes to the core of Tapestry's IoC that would definitely result in API break. At least the Spring guys also say so about their framework. I am not sure if it is possible or not to integrate CDI without breaking backwards compatibility... but it is something we should find out. Spring guys are no reliable source, they want to sell their product and if I were them, I would fear CDI as well. I have an idea, may be a controversial one. I've seen much about Tapestry and think it's a nice Framework. But what I still don't understand is why it's not widely in use. It existed before Wicket but Wicket is far more popular. I don't think it's only because it's users are very vocal. There is also a saying that a good product sometimes sells itself. I've also thought about this, and my only conclusion is that Tapestry is too difficult to master. Especially when it comes to tapestry-ioc and getting productive with it. I am not talking about building the frontend and components.. this is easy and IMHO the thing where tapestry really shines. But there are way too less integrations - see my tapestry-jpa experiment for an example. It works, but it would need some love from some smarter people than me to get proper unit tests and some missing parts. If I look at Wicket or other frameworks there are lots and lots of integration modules for just everything. Why is that? My answer is because it is way easier to write them. My proposition is why not let Tapestry and Wicket join hands, migrate some of the nice ideas to Wicket and lets try to go standardize Wicket as a JSR. I am not sure I would like this. I've tried wicket in the past, and for me it is too verbose. I don't like the Swing-Approach and these inner classes everywhere. Tapestry's approach to the front-end programming is excellent, I don't want to trade this. But I would be perfectly fine trading the IoC container... Piero - 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: Discussion
Em Wed, 23 Dec 2009 08:28:35 -0200, Piero Sartini li...@pierosartini.de escreveu: I am not sure if it is possible or not to integrate CDI without breaking backwards compatibility... but it is something we should find out. Agreed. :) I've also thought about this, and my only conclusion is that Tapestry is too difficult to master. Especially when it comes to tapestry-ioc and getting productive with it. What exactly is difficult to master? I think Tapestry-IoC is easier to learn than Spring. Maybe there's a sensation of Tapestry being hard to master because it's built on IoC and has many hooks to do many things. Other frameworks has many hooks, but less ways to customize them without changing the sources or doing difficult configurations. If I look at Wicket or other frameworks there are lots and lots of integration modules for just everything. Why is that? My answer is because it is way easier to write them. I guess is that because these frameworks are older and people had more time to write these integration modules. Tapestry 5 is way younger, specially when you think that the first stable version was released in December 18th, 2009, one year and 5 days ago. Wicket 1.0 was released in June 2005, 4.5 years ago. That's a 3.5 years head start. There isn't an integration with JFreeChart or JasperReports, for example, maybe because it's so easy to write it (a page returning StreamResponse in its onActivate() method). But I would be perfectly fine trading the IoC container... The day you understand distributed configuration I guess you'll change your mind. :) I also use Spring, and I think Tapestry-IoC is bothe easier and more powerful. But what exactly do you find difficult in Tapestry-IoC? What could be easier? What could be better documented? What have you tried to do with T-IoC and failed? Feedback is very important and we can use it to improve Tapestry and Tapestry-IoC. ;) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
I've also thought about this, and my only conclusion is that Tapestry is too difficult to master. Especially when it comes to tapestry-ioc and getting productive with it. What exactly is difficult to master? I think Tapestry-IoC is easier to learn than Spring. Maybe there's a sensation of Tapestry being hard to master because it's built on IoC and has many hooks to do many things. Other frameworks has many hooks, but less ways to customize them without changing the sources or doing difficult configurations. I never liked Spring because of its XML configuration. I like guice and tapestry-ioc better. What I meant is that it is hard to find your way around the IoC concepts neccessary to master tapestry.. I am learning something new every day, and do develop with tapestry 5 for about one year now. Some people say it is over engineered - I don't think so. But maybe its exposing too much of its excellence to the user, forcing us to be as excellent as the developers. Which brings me to another point: It is hard to contribute to tapestry, because you need a very high skillset to join the effort. It's _way_ easier to contribute to wicket or struts2. Result is, of course, that their codebase is not nearly as good as tapestry's. If I look at Wicket or other frameworks there are lots and lots of integration modules for just everything. Why is that? My answer is because it is way easier to write them. I guess is that because these frameworks are older and people had more time to write these integration modules. Tapestry 5 is way younger, specially when you think that the first stable version was released in December 18th, 2009, one year and 5 days ago. Wicket 1.0 was released in June 2005, 4.5 years ago. That's a 3.5 years head start. That may be one point. But our module landscape outside the core is really thin. And it is also hard to build some modules, because it would not be the tapestry way. Think about jQuery or other JS libraries (ExtJS, Dojo, etc) for example (IMHO the Prototype dependency frightened a lot of people). If you remember some weeks back, I was trying to integrate YAML (Yet another Multicolumn Layout: http://www.yaml.de) with tapestry... I gave up. Maybe because of lacking tapestry documentation.. but it is really not as easy as it should be! Tapestry claims to be flexible.. but adopting it to your needs is difficult (and not documented). There isn't an integration with JFreeChart or JasperReports, for example, maybe because it's so easy to write it (a page returning StreamResponse in its onActivate() method). I agree :) But I would be perfectly fine trading the IoC container... The day you understand distributed configuration I guess you'll change your mind. :) Guice does have all of this as well (and comes with warp-persist, offering JPA and db4o integrations - transactions as well). By the way, look out for google sitebricks... it reminds me a lot of tapestry. I also use Spring, and I think Tapestry-IoC is bothe easier and more powerful. See below, I don't even tried to use Spring starting with EJB3 there was no need to do so. But what exactly do you find difficult in Tapestry-IoC? What could be easier? What could be better documented? What have you tried to do with T-IoC and failed? Feedback is very important and we can use it to improve Tapestry and Tapestry-IoC. ;) See above for two modules I tried to build with tapestry-ioc. My conclusion is that integrating third-party modules is too difficult. What I would love to be better documented is how to adopt the markup to your needs. Changing CSS is easy - but I did not find out how to change the markup yet. Piero - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Em Wed, 23 Dec 2009 09:20:05 -0200, Piero Sartini li...@pierosartini.de escreveu: I never liked Spring because of its XML configuration. There's also JavaConfig and use of annotations instead of XML, but Tapestry-IoC still looks better to me. And Spring doesn't have distributed configuration. I like guice and tapestry-ioc better. Guice inspired Tapestry-IoC. :) What I meant is that it is hard to find your way around the IoC concepts neccessary to master tapestry.. What concepts exactly? Some people say it is over engineered - I don't think so. But maybe its exposing too much of its excellence to the user, forcing us to be as excellent as the developers. Please give us some examples. Which brings me to another point: It is hard to contribute to tapestry, because you need a very high skillset to join the effort. It's _way_ easier to contribute to wicket or struts2. Result is, of course, that their codebase is not nearly as good as tapestry's. You can also contribute by writing libraries. ;) That may be one point. But our module landscape outside the core is really thin. And it is also hard to build some modules, because it would not be the tapestry way. Please give us some examples of hard-to-build modules. Think about jQuery or other JS libraries (ExtJS, Dojo, etc) for example (IMHO the Prototype dependency frightened a lot of people). This point was discussed a lot and I have a component that uses a very nice jQuery color picker and it works. If you remember some weeks back, I was trying to integrate YAML (Yet another Multicolumn Layout: http://www.yaml.de) with tapestry... I gave up. From a quick read (I'm busy writing a Tapestry course now), it seems that YAML is a CSS framework. The thread is here: http://old.nabble.com/Customize-markup-of-client-side-validation-to26668520s302.html#a26668520 There was a solution proposed (your own ValidationDecorator). Have you had problems with this approach? Maybe because of lacking tapestry documentation.. but it is really not as easy as it should be! Tapestry claims to be flexible.. but adopting it to your needs is difficult (and not documented). The documentation has been improved by Howard and you can see its progress here: http://tapestry.formos.com/nightly/tapestry5/ The day you understand distributed configuration I guess you'll change your mind. :) Guice does have all of this as well Guice has distributed configuration, but not explicitly and not as easy as in Tapestry-IoC. (and comes with warp-persist, offering JPA and db4o integrations - transactions as well). In this case, it seems to me it's a matter of money. Many people at Google work on it in their paid time, while almost everyone working on Tapestry work in their free time. See above for two modules I tried to build with tapestry-ioc. I'm sorry, but your examples weren't enough for me to understand. One counter-example: in my Ars Machina Project, I have authentication and authorization packages. I only need to add annotations to my page classes to inform if it needs a logged user and/or what roles the need use to be able to use that page. I have an access logger package that works just by adding it to the classpath. What I would love to be better documented is how to adopt the markup to your needs. Changing CSS is easy - but I did not find out how to change the markup yet. The markup is responsibility of each component. You can write a mixin to change the generated markup or write your own components. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Please give us some examples of hard-to-build modules. Distributed configuration is great for something simple, but to use it for something more involved can be tricky, for example Tapestry IoC provides the platform for developing IoC services, but doesn't follow through with web services integration. Restful web services are easy but for a complete web services stack (METRO, CXF etc...) you need much more plumbing. This type of integration comes out of the box in Spring and grails... there are few docs on this type of thing, so basically the route we are advised to take is to join the two contexts, but this is hardly the Tapestry way. Peter -- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail. - Original Message - From: Thiago H. de Paula Figueiredo thiag...@gmail.com To: Tapestry users users@tapestry.apache.org Sent: Wednesday, 23 December, 2009 13:47:54 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Discussion Em Wed, 23 Dec 2009 09:20:05 -0200, Piero Sartini li...@pierosartini.de escreveu: I never liked Spring because of its XML configuration. There's also JavaConfig and use of annotations instead of XML, but Tapestry-IoC still looks better to me. And Spring doesn't have distributed configuration. I like guice and tapestry-ioc better. Guice inspired Tapestry-IoC. :) What I meant is that it is hard to find your way around the IoC concepts neccessary to master tapestry.. What concepts exactly? Some people say it is over engineered - I don't think so. But maybe its exposing too much of its excellence to the user, forcing us to be as excellent as the developers. Please give us some examples. Which brings me to another point: It is hard to contribute to tapestry, because you need a very high skillset to join the effort. It's _way_ easier to contribute to wicket or struts2. Result is, of course, that their codebase is not nearly as good as tapestry's. You can also contribute by writing libraries. ;) That may be one point. But our module landscape outside the core is really thin. And it is also hard to build some modules, because it would not be the tapestry way. Please give us some examples of hard-to-build modules. Think about jQuery or other JS libraries (ExtJS, Dojo, etc) for example (IMHO the Prototype dependency frightened a lot of people). This point was discussed a lot and I have a component that uses a very nice jQuery color picker and it works. If you remember some weeks back, I was trying to integrate YAML (Yet another Multicolumn Layout: http://www.yaml.de) with tapestry... I gave up. From a quick read (I'm busy writing a Tapestry course now), it seems that YAML is a CSS framework. The thread is here: http://old.nabble.com/Customize-markup-of-client-side-validation-to26668520s302.html#a26668520 There was a solution proposed (your own ValidationDecorator). Have you had problems with this approach? Maybe because of lacking tapestry documentation.. but it is really not as easy as it should be! Tapestry claims to be flexible.. but adopting it to your needs is difficult (and not documented). The documentation has been improved by Howard and you can see its progress here: http://tapestry.formos.com/nightly/tapestry5/ The day you understand distributed configuration I guess you'll change your mind. :) Guice does have all of this as well Guice has distributed configuration, but not explicitly and not as easy as in Tapestry-IoC. (and comes with warp-persist, offering JPA and db4o integrations - transactions as well). In this case, it seems to me it's a matter of money. Many people at Google work on it in their paid time, while almost everyone working on Tapestry work in their free time. See above for two modules I tried to build with tapestry-ioc. I'm sorry, but your examples weren't enough for me to understand. One counter-example: in my Ars Machina Project, I have authentication and authorization packages. I only need to add annotations to my page classes to inform if it needs a logged user and/or what roles the need use to be able to use that page. I have an access logger package that works just by adding it to the classpath. What I would love to be better documented is how to adopt the markup to your needs. Changing CSS is easy - but I did not find out how to change the markup yet. The markup is responsibility of each component. You can write a mixin to change the generated markup or write your own components. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br
Re: Discussion
Il 23/12/2009 11:28, Piero Sartini ha scritto: I have an idea, may be a controversial one. I've seen much about Tapestry and think it's a nice Framework. But what I still don't understand is why it's not widely in use. It existed before Wicket but Wicket is far more popular. I don't think it's only because it's users are very vocal. There is also a saying that a good product sometimes sells itself. I've also thought about this, and my only conclusion is that Tapestry is too difficult to master. Especially when it comes to tapestry-ioc and getting productive with it. As a newbie, I have to say that learning Tapestry (5) is actually a little bit more complicated than what you could expect after having read the available marketing documentation. Maybe this (apparently steep) learning curve has kept the masses of developers/users away from Tapestry. Nevertheless, this apparent difficulty is in large part just a matter of documentation and/or examples. From this point of view, Wicket seems to be much more appetizing. Just have a look at these pages: http://wicketstuff.org/wicket13/ http://sourceforge.net/projects/wicket-stuff/files/ It is not surprising that many developers could prefer a framework that supply them with a lot of working, ready-to-use components and/or a lot of code examples. BEWARE: I'm not saying that Wicket /is/ better or more complete than Tapestry. I'm just saying that Wicket is /presented/ (or /offered/) to the public in a better way. I think that it is possible to fill this gap, for example using Tynamo and AppFuse as examples/codebases. At the end, it is just a matter of documentation and support. I am not talking about building the frontend and components.. this is easy and IMHO the thing where tapestry really shines. I agree. Tapestry is much more elegant than many other frameworks from this point of view. This part of Tapestry should not be under discussion. I do not know if the IoC container is the real and sole source of the scarce appreciation of Tapestry (if even exists such a scarce appreciation) but... see below. But there are way too less integrations - see my tapestry-jpa experiment for an example. It works, but it would need some love from some smarter people than me to get proper unit tests and some missing parts. If I look at Wicket or other frameworks there are lots and lots of integration modules for just everything. Why is that? My answer is because it is way easier to write them. I'm afraid you are right: /this/ seems to be the main, real weak point of Tapestry. I do not know Tapestry well enough to have a solid opinion about this topic but it seems to me quite evident that writing an integration module is somehow (much?) more difficult than it should be. Unfortunately, this can be a heavy limit for Tapestry. A real webapp very often uses many external modules and the simple fact of not having a easy way to write and/or integrate them can be a good reason for abandoning this framework. I came from the Python world and, as you probably know, a large part of the success of Python is related to the easyness of integrating existing C and C++ library with the Python interpreter (using SIP or SWIG). It seems to me a lesson to learn. I wonder: is it possible to improve the existing integration mechanism of Tapestry (that is: the existing IoC container)? How? Or should we replace it with a different/new one? Which one? JM2C -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ Who wants to remember that escape-x-alt-control-left shift-b puts you into super-edit-debug-compile mode? -- (Discussion in comp.os.linux.misc on the intuitiveness of commands, especially Emacs.) - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Em Wed, 23 Dec 2009 10:13:59 -0200, p.stavrini...@albourne.com escreveu: Please give us some examples of hard-to-build modules. Distributed configuration is great for something simple, but to use it for something more involved can be tricky, for example Tapestry IoC provides the platform for developing IoC services, but doesn't follow through with web services integration. I wasn't clear: when I'm comparing Tapestry-IoC with Spring, I'm actually comparing it to Spring-Core itself, not to the whole Spring ecosystem. There's no doubt that Tapestry-IoC lacks some integration with other packages when compared to other IoC frameworks. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Em Wed, 23 Dec 2009 10:14:53 -0200, Alessandro Bottoni alexbott...@gmail.com escreveu: As a newbie, I have to say that learning Tapestry (5) is actually a little bit more complicated than what you could expect after having read the available marketing documentation. This is a known issue. Maybe this (apparently steep) learning curve has kept the masses of developers/users away from Tapestry. You can use Tapestry almost without using Tapestry-IoC, so I don't thin BEWARE: I'm not saying that Wicket /is/ better or more complete than Tapestry. I'm just saying that Wicket is /presented/ (or /offered/) to the public in a better way. I think you're probably right. I do not know if the IoC container is the real and sole source of the scarce appreciation of Tapestry (if even exists such a scarce appreciation) but... see below. I don't think so. I'm afraid you are right: /this/ seems to be the main, real weak point of Tapestry. I do not know Tapestry well enough to have a solid opinion about this topic but it seems to me quite evident that writing an integration module is somehow (much?) more difficult than it should be. I think you're looking for the cause in the wrong places. I guess these integratiosn weren't written just because, unfortunately, Tapestry is not very well-known, so few people use it and write extensions and integrations. Or Tapestry users didn't have the need to write them. The recentness of Tapestry doesn't help either. Take a look at the t5-restful-webservices project written by Bill Holloway: http://code.google.com/p/t5-restful-webservices/wiki/GettingStarted. It implements JSR 311: JAX-RS: The JavaTM API for RESTful Web Services for Tapestry. Take a look at the sources. Just three classes, none of them large. Spring integration has a small number of lines of code. 11 kb total. There's integration with Tapestry Spring Security. It isn't hard, people haven't had the time or need to write them. I wonder: is it possible to improve the existing integration mechanism of Tapestry (that is: the existing IoC container)? How? It would be better to discuss actual integration problems and them attack them. If anyone has already had them, please post they here. Or should we replace it with a different/new one? Which one? I don't see any reason at all to replace it. If it has shortcomings, let's fix them! :) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
with Tapestry-Hibernate now it would be hard to something that would work with other persistence options. I strongly suggest you to not make bold statements about frameworks you don't know very well. ;) It makes you sound like an uninformed troll, but I know you're not one, as you made some very good points in this discussion. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Il 23/12/2009 13:45, Thiago H. de Paula Figueiredo ha scritto: I think you're looking for the cause in the wrong places. I guess these integratiosn weren't written just because, unfortunately, Tapestry is not very well-known, so few people use it and write extensions and integrations. Hence, the relatively scarce fame of Tapestry can be considered a problem in itself. If few people know Tapestry and few people write few code and support it, then the whole framework became less palatable. Maybe, we should do something about it... For what regards me, I still hope to be able to write some docu/article/marketing stuff in the near future (with the help of the members of this list, of course). Let's hope this helps. I wonder: is it possible to improve the existing integration mechanism of Tapestry (that is: the existing IoC container)? How? It would be better to discuss actual integration problems and them attack them. If anyone has already had them, please post they here. Or should we replace it with a different/new one? Which one? I don't see any reason at all to replace it. If it has shortcomings, let's fix them! :) Well, I'm not sure that the T5 IoC container is completely innocent. It is true that T5 IoC is much lighter and much more manageable than the Spring's one. It is also true that its mechanism of configuration is very elegant. Nevertheless, I wonder if its original architecture represents a barrier for the programmers used to Spring IoC or other containers. Maybe it is just a matter of pre-existing skills and programming habits. Maybe a compatibility layer could help (for example: accepting both the T5 and the Spring configuration sintax). Or, maybe, it is a subtle matter of compatibility between the T5 IoC container and the modules we try to integrate (given that most of them were designed to work with other types of IoC containers). I wonder, for example, if there is some Spring IoC (or other IoC container) feature that is missing in the T5 IoC and that can make any difference. Could it be a (maybe obscure) missing feature the reason why a few programmers find so hard to develop a module integration library? Anyway, these are JM2C. -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. — Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Em Wed, 23 Dec 2009 12:07:21 -0200, Alessandro Bottoni alexbott...@gmail.com escreveu: Hence, the relatively scarce fame of Tapestry can be considered a problem in itself. If few people know Tapestry and few people write few code and support it, then the whole framework became less palatable. Maybe, we should do something about it... You've hit the head of the nail. ;) For what regards me, I still hope to be able to write some docu/article/marketing stuff in the near future (with the help of the members of this list, of course). Let's hope this helps. It surely helps. Well, I'm not sure that the T5 IoC container is completely innocent. It is true that T5 IoC is much lighter and much more manageable than the Spring's one. It is also true that its mechanism of configuration is very elegant. :) Nevertheless, I wonder if its original architecture represents a barrier for the programmers used to Spring IoC or other containers. It will be a barrier for anyone used to another IoC container. The architecture of IoC containers, AFAIK, is very similar to each other. You have beans/services, dependency injection, AOP, no much beyond that. Maybe it is just a matter of pre-existing skills and programming habits. I don't know if this is an issue, but it is for almost anything in software development. That's exactly why I think many people still use Struts when there are many better alternatives. Inertia. Maybe a compatibility layer could help (for example: accepting both the T5 and the Spring configuration sintax). This could be added to the Spring integration, except the XML part, that is awful. Or, maybe, it is a subtle matter of compatibility between the T5 IoC container and the modules we try to integrate (given that most of them were designed to work with other types of IoC containers). The Spring integration does that. We could also do similar integrations with EJB3, Weld (for CDI), etc. I wonder, for example, if there is some Spring IoC (or other IoC container) feature that is missing in the T5 IoC and that can make any difference. Could it be a (maybe obscure) missing feature the reason why a few programmers find so hard to develop a module integration library? I don't think so. IoC containers features are similar. Comparing Spring-Core, Tapestry-IoC and Guice, AFAIK, Spring has no feature that the others don't have. On the other hand, Spring is way older (1.0 released in 2004!) and they have a company behind it, so they can pay people to work on it full time. I still think it's more a matter of someone having the time and need. Anyway, these are JM2C. Thanks for contributing to the discussion. :) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Noe, I've been down this path before, regrettably. The ONLY thing to do it to ignore the trolls. On Tue, Dec 22, 2009 at 11:29 PM, Newham, Cameron cameron.new...@bl.uk wrote: I don't agree with the OP that the ServerSide discussion shows Tapestry has lost the battle - two posters state they don't want to see Tapestry mentioned. That's all there is. However, I can't agree with you Thiago. The old saying is if you say it enough times then people will believe it is true. If you are just going to stand by and let trolls post bad things about Tapestry unchallenged then they have won the argument - regardless of how bad their argument may be and how incorrect their views may be. After all, someone pitching up and wanting a framework will read what they've written and believe it. Who is to say these anti-Tapestry people are wrong? Not you - because you won't counter their arguments! :-) Sure - don't feed the trolls. But all that is necessary is to say something positive; not engage them in an argument. Merry Xmas everyone. -Original Message- From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com] Sent: 22 December 2009 15:26 To: Tapestry users Subject: Re: Discussion Em Tue, 22 Dec 2009 12:45:20 -0200, Banchi Liko banchi...@gmail.com escreveu: Hi guys, Hi! There is a discussion going on here http://www.theserverside.com/news/thread.tss?thread_id=58858 and seems like Tapestry ihas already been ruled out as a viable and serious web framework. TheServerSide comments has too many trolls to have a good, reasonable discussion there. Wicket seems to be the favorite. Some people who bother to post there like Wicket. Most people who like Tapestry, maybe all of them, don't bother to post there. I'm sad Tapestry has lost the battle and afraid it might die soon. Please source or explain your statements or you'll be treated like a troll here. Please go and contribute and let your voice be heard before Tapestry dies a horrible death. No, thank you. Posting there will not change Tapestry's fate. Using it, exchanging ideas in the mailing lists and contributing code will (and already is). -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - 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 -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Select models out of beans could be improved. My Tapestry CRUD package has a solution for that. I know... but your CRUD package is not tapestry. You're talking about a snapshot. This behaviour was changed and now everything in the context is allowed. Hey.. this was no complain, you asked where documentation could be improved ;-) In the backend, it gets more complicated: contributing services, decorating services, overriding services... I don't think they're complicated. That's your oppinion... my feeling is the opposite. On its own, these things are simple - but in context of a complex framework like tapestry, its hard to get the big picture. You should know I've tried ;-) BTW the libraries are spread all over the web (google code, kenai, github, tap360..). There are links to them in http://tapestry.apache.org/. The problem is that tapestry.apache.org is static. It can be edited by the commiters only. My feeling is that this forces the community to a single place: the mailing lists. I am not sure if this is enough to build an opensource community around a framework like tapestry. Of course there is the wiki - but it is hidden behind lots of menu entries. CDI and JPA were released few weeks ago and they were mostly written to be used inside an EJB container. Implementing CDI is not a piece of cake. JPA is available since over 3 years. And I disagree: it is not mainly written to be used inside an EJB container. JPA2 is new.. but maybe you know that there is a half-finnished module available. All it does is to provide Spring beans as Tapestry services. :) Not the other way as well(tapestry services as spring beans?) .. ? You're changing the output generated by some. Try to do the same in another framework. ;) The documentation could mention it, of course. In other frameworks the output is not that static... and such basic things like where to add the error messages is easy to change. Take Struts2 for an example: s:error for=fieldNameError message for Field/s:error There are many ways of modeling and implementing authentication and authorization, so I think it's not a Tapestry responsibility. I think it is - security is something needed by the majority of webapps. Tapestry wants to be my web framework - so why doesn't it help me? Using container based authentication is not possible. Its hard for newbies to get around this. Not more and not less. Besides the proxy issue, you're wrong: it wouldn't be difficult to integrate with Tapestry-Hibernate now it would be hard to something that would work with other persistence options. I was not aware of the proxy issue, but I was right that it can't be too easy. Anyway, IMHO we should need to think about a more general way of handling persistence. ORMs (aka JPA and Hibernate) are just one part of the persistence arena.. I strongly suggest you to not make bold statements about frameworks you don't know very well. ;) It makes you sound like an uninformed troll, but I know you're not one, as you made some very good points in this discussion. If I sound like an uninformed troll, that is because I did not manage to understand everything good enough. One possibility is that I am just too dumb, the other one would be that tapestry is quite complex (what is my whole point above)... (please resist to answer this question ;-) Piero - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Em Wed, 23 Dec 2009 15:42:20 -0200, Piero Sartini li...@pierosartini.de escreveu: I know... but your CRUD package is not tapestry. It's a Tapestry extension that I plan to contribute to Tapestry itself when is good enough (a.k.a. it has unit tests). That's your oppinion... my feeling is the opposite. On its own, these things are simple - but in context of a complex framework like tapestry, its hard to get the big picture. If it's possible and easy to do what you want but you don't know how, then I think we have an issue with the documentation, not with the framework itself. The problem is that tapestry.apache.org is static. It can be edited by the commiters only. Just post a JIRA and it's added there. Of course, a more dynamic page would be a nicer solution. CDI and JPA were released few weeks ago and they were mostly written to be used inside an EJB container. Implementing CDI is not a piece of cake. JPA is available since over 3 years. And I disagree: it is not mainly written to be used inside an EJB container. I wrote that because of the @PersistenceContext. That's the only thing, AFAIK, that would be different from tapestry-hibernate. JPA2 is new.. but maybe you know that there is a half-finnished module available. Yes, I know. :) All it does is to provide Spring beans as Tapestry services. :) Not the other way as well(tapestry services as spring beans?) .. ? Tapestry-Spring supports both. In other frameworks the output is not that static... and such basic things like where to add the error messages is easy to change. Take Struts2 for an example: s:error for=fieldNameError message for Field/s:error You can do this in Tapestry too, but not in the template. It goes in app.properties. From http://tapestry.apache.org/tapestry5.1/guide/validation.html The first key checked is formId-fieldId-validatorName-message. formId: the local component id of the Form component fieldId: the local component id of the field (TextField, etc.) validatorName: the name of the validator, i.e., required or minlength If there is not message for that key, a second check is made, for fieldId-validatorName-message. If that does not match a message, then the built-in default validation message is used. I think it is - security is something needed by the majority of webapps. Tapestry wants to be my web framework - so why doesn't it help me? Using container based authentication is not possible. Its hard for newbies to get around this. Not more and not less. I really dislike container-based authentication. I think it should be implemented by the application. I was not aware of the proxy issue, but I was right that it can't be too easy. Anyway, IMHO we should need to think about a more general way of handling persistence. ORMs (aka JPA and Hibernate) are just one part of the persistence arena.. The only part I can think that can be the same across different ORM frameworks is transaction handling. And a tapestry-tx package is a dream of mine. If I sound like an uninformed troll, You just sounded like a troll when you made several about why we don't have more integrations in Tapestry-IoC without writing one. The rest is a nice discussion. :) that is because I did not manage to understand everything good enough. One possibility is that I am just too dumb, I guess not. :) the other one would be that tapestry is quite complex (what is my whole point above)... (please resist to answer this question ;-) Different points of view, different minds, different opinions. Sorry, I answered your question. :) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
I wrote that because of the @PersistenceContext. That's the only thing, AFAIK, that would be different from tapestry-hibernate. From a users perspective, its a matter of injecting EntityManager instead of hibernate's Session. In the module itself there are more changes. You can do this in Tapestry too, but not in the template. It goes in app.properties. From http://tapestry.apache.org/tapestry5.1/guide/validation.html The first key checked is formId-fieldId-validatorName-message. formId: the local component id of the Form component fieldId: the local component id of the field (TextField, etc.) validatorName: the name of the validator, i.e., required or minlength If there is not message for that key, a second check is made, for fieldId-validatorName-message. If that does not match a message, then the built-in default validation message is used. Nope, that is the error message only. What I would like to define is where the message should be rendered.. and control the markup ;-) Right now, the client-side validation is kind of a blackbox. It renders its bubbles with the messages... but if you don't want to have these bubbles but your own markup, you need to do things like override services you never heard about. As said before, need to look at the ValidationDecorator again, but my feeling still is that this is not as easy as it should be. I really want to be able to define where my client-side error messages should appear inside the template (very important: how the markup should look like) I really dislike container-based authentication. I think it should be implemented by the application. I don't like it as well - but tapestry should provide an alternative. Maybe the question is if tapestry wants to be a full-stack framework or just deliver some building blocks. For being a full-stack framework, there is not enough functionality available. To just provide building blocks, it dictates too much (javascript library, markup, and so on). Of course this is just my feeling. And don't get me wrong: I really like tapestry and hava already built some projects with it. My reason for all this complaining is just to make it even better :-) The only part I can think that can be the same across different ORM frameworks is transaction handling. And a tapestry-tx package is a dream of mine. Different ORM frameworks do share much more in common: see JPA2 for what is standardized between them. For other persistence solutions (like OODBMs, Google BigTable, HBase and so on) it gets more difficult... but JDO tries to provide a standard for all persistence needings. tapestry-tx could integrate with tapestry-jpa and tapestry-jdo ,-) Piero - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Em Wed, 23 Dec 2009 16:22:49 -0200, Piero Sartini li...@pierosartini.de escreveu: I wrote that because of the @PersistenceContext. That's the only thing, AFAIK, that would be different from tapestry-hibernate. From a users perspective, its a matter of injecting EntityManager instead of hibernate's Session. In the module itself there are more changes. I don't know Tapestry-IoC from the inside (yet!), so I don't know how difficult it would be to provide an injection for @PersistenceContext. It would be straightforward for @Inject. Nope, that is the error message only. What I would like to define is where the message should be rendered.. and control the markup ;-) This is done by ValidationDecorator. You can implement your own one and overrid the DefaultValidationDecorator contribution to the MarkupRenderer service. I have not tested yet, though. Right now, the client-side validation is kind of a blackbox. It renders its bubbles with the messages... but if you don't want to have these bubbles but your own markup, you need to do things like override services you never heard about. Or disable client-side validation entirely. Agreed with the rest. As said before, need to look at the ValidationDecorator again, but my feeling still is that this is not as easy as it should be. I really want to be able to define where my client-side error messages should appear inside the template (very important: how the markup should look like) More freedom, more control, more complex. Quite hard to avoid that. I don't like it as well - but tapestry should provide an alternative. Maybe the question is if tapestry wants to be a full-stack framework or just deliver some building blocks. For being a full-stack framework, there is not enough functionality available. To just provide building blocks, it dictates too much (javascript library, markup, and so on). Of course this is just my feeling. I cannot speak for the project, but I think Tapestry tries to be a Web framework, not a full stack. At least not yet. ;) And don't get me wrong: I really like tapestry and hava already built some projects with it. My reason for all this complaining is just to make it even better :-) :) Different ORM frameworks do share much more in common: see JPA2 for what is standardized between them. For other persistence solutions (like OODBMs, Google BigTable, HBase and so on) it gets more difficult... but JDO tries to provide a standard for all persistence needings. I was talking about a really generic tapestry-tx that could be used with any persistence technology, being it backed by relational database or not. IMHO, using JPA or JDO over a non-relational database loses some of the benefits of it. I plan to write some projects to run on Google Application Engine and I'm going to use the low-level API. tapestry-tx could integrate with tapestry-jpa and tapestry-jdo ,-) That's my plan. ;) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
More freedom, more control, more complex. Quite hard to avoid that. Agreed. The challange is to define what parts need to be customized often, and should be easy to change. For me, these bubbles should be easy to change.. but as always, others may have a different oppinion. I cannot speak for the project, but I think Tapestry tries to be a Web framework, not a full stack. At least not yet. ;) For me, authentication is an important part of a web framework and should provide some standard way to do so. I was talking about a really generic tapestry-tx that could be used with any persistence technology, being it backed by relational database or not. Great! Really looking forward to this. IMHO, using JPA or JDO over a non-relational database loses some of the benefits of it. I plan to write some projects to run on Google Application Engine and I'm going to use the low-level API. Agreed. The native APIs are much easier in many cases. JPA as a whole does not even fit well with non relational databases. JDO on the other hand does - it was designed from the ground up to support different types of persistence engines. Piero - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Em Wed, 23 Dec 2009 17:37:24 -0200, Piero Sartini li...@pierosartini.de escreveu: For me, authentication is an important part of a web framework and should provide some standard way to do so. Wicket itself doesn't. Nor does JSF. (all this as far as I know and I google it) There is a third-party package for Wicket: http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security. For Tapestry, there's ChenilleKit Access: http://www.chenillekit.org/chenillekit-access/ Great! Really looking forward to this. Me too. :) JDO on the other hand does - it was designed from the ground up to support different types of persistence engines. I never paid attention to JDO. Wouldn't be the case case as JPA regarding use of low-level APIs? Regarding JDO, its implementations need for class enhancement after compilation is something very annoying. Am I right? -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Wicket itself doesn't. Nor does JSF. (all this as far as I know and I google it) JSF does not qualify as framework IMHO. Seam brings security. Agreed on chenillekit. By the way, it would be nice to have something like wicketstuff.org :-) Regarding JDO, its implementations need for class enhancement after compilation is something very annoying. Am I right? Yes, you are. Just wanted to mention that there is something not that RDBMS specific than JPA. I think I would prefer the native APIs as well - or maybe NeoDatis v2 if there exists a backend for the db to use. I like the easy to use api and the clean queries. Piero - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
A few thoughts from this discussion: Tapestry site needs: 1. immediately visible search field over all valuable resources, like wiki. We were discussing custom google search that makes it. 2. A few more diagrams, like http://tapestry.apache.org/tapestry5.1/images/component-render-states.png
Re: Discussion
Em Wed, 23 Dec 2009 19:19:17 -0200, Alfonso Quiroga alfonsose...@gmail.com escreveu: Hi! very interesting thread. I use T5 since 1 year aprox, and it's true that T-IOC was the first wall I had, now I understand it and I like it a lot (my system does NOT use spring, all with t-ioc). I don't know which is the solution, because there is documentation about t-ioc, but maybe more documentation? or maybe a demo-project that uses basic t-ioc. I think is easier seeing something working, than reading t-ioc documentation and start from scratch. Better documentation and examples are a very good idea. :) Demo projects would really help. Something like the Guice introduction would be nice. Another point.. I think it's impossible to use T5 without t-ioc, is this right? If it's possible, it would be a good idea uploading another demo-project without t-ioc. It's impossible. T5 uses T-IoC in every way possible. T-IoC was created for T5 because none of the IoC containers at that time provided everything T5 needs. What else? js.. prototype-based, I know it's possible to have prototype+jquery together, but I can see lot of people heading jquery, so I have a long-term plan.. make a tapestry.js based on jquery, if I do it obviously I'll share it. There's a plan not to switch from Prototype to jQuery. There's a plan to have JavaScript stacks, one implemented with Prototype, another with jQuery. No dates yet. But the solution for this would be a tapestry.js agnostic, so people can inject their favourite framework. So, maybe it could be shipped with a default prototype injection, but anyone could write a mootols injection, jquery injection, etc etc The plan looks like your description. :) Lot of work to implement it, though. It would be almost something like a JavaScript framework abstraction layer. Last, it would be good more components (ui components). Agreed. Don't forget to check the third-party packages in the Tapestry home page. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
Agreed. Don't forget to check the third-party packages in the Tapestry home page. Talking about these.. It would be great to tag them defining what they are about: * projects using tapestry (like InterLDAP) * projects providing extensions * showcase / tutorial projects Outdated: * Godcode Components joined effort with tapestry-components. * t5Components is now chenillekit! (link broken on frontpage). * loom-t5 is inactive Piero - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
On 23.12.2009 22:37, Thiago H. de Paula Figueiredo wrote: Better documentation and examples are a very good idea. :) Demo projects would really help. Something like the Guice introduction would be nice. I hope we (our team) will soon agree with the licencing issues of our own project and open-source the part that is finished. It might not be the best practice example, but it is a complete code piece that is in production (60-70 database tables, 100 tapestry pages) and an example what a dozen of students can do in 3-4 months (studying other courses, learning tapestry included). I would welcome others to do so in any matter possible (if it is possible). The best way to learn is by example. smime.p7s Description: S/MIME Cryptographic Signature
Discussion
Hi guys, There is a discussion going on here http://www.theserverside.com/news/thread.tss?thread_id=58858 and seems like Tapestry ihas already been ruled out as a viable and serious web framework. Wicket seems to be the favorite. I'm sad Tapestry has lost the battle and afraid it might die soon. Please go and contribute and let your voice be heard before Tapestry dies a horrible death. Banchi
Re: Discussion
Em Tue, 22 Dec 2009 12:45:20 -0200, Banchi Liko banchi...@gmail.com escreveu: Hi guys, Hi! There is a discussion going on here http://www.theserverside.com/news/thread.tss?thread_id=58858 and seems like Tapestry ihas already been ruled out as a viable and serious web framework. TheServerSide comments has too many trolls to have a good, reasonable discussion there. Wicket seems to be the favorite. Some people who bother to post there like Wicket. Most people who like Tapestry, maybe all of them, don't bother to post there. I'm sad Tapestry has lost the battle and afraid it might die soon. Please source or explain your statements or you'll be treated like a troll here. Please go and contribute and let your voice be heard before Tapestry dies a horrible death. No, thank you. Posting there will not change Tapestry's fate. Using it, exchanging ideas in the mailing lists and contributing code will (and already is). -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
I agree with Thiago, but I've never used Wicket. I've used tapestry5 and I really like it. Both frameworks are component-based, maybe some day I'll try wicket. But if tap5 works for me... why do I have to discuss in server-side? I prefer to share my solutions and workarounds in this list, where there are people really interested in T5. Ah! greeting to Thiago from Messi's country, :) :) On Tue, Dec 22, 2009 at 12:25 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: Em Tue, 22 Dec 2009 12:45:20 -0200, Banchi Liko banchi...@gmail.com escreveu: Hi guys, Hi! There is a discussion going on here http://www.theserverside.com/news/thread.tss?thread_id=58858 and seems like Tapestry ihas already been ruled out as a viable and serious web framework. TheServerSide comments has too many trolls to have a good, reasonable discussion there. Wicket seems to be the favorite. Some people who bother to post there like Wicket. Most people who like Tapestry, maybe all of them, don't bother to post there. I'm sad Tapestry has lost the battle and afraid it might die soon. Please source or explain your statements or you'll be treated like a troll here. Please go and contribute and let your voice be heard before Tapestry dies a horrible death. No, thank you. Posting there will not change Tapestry's fate. Using it, exchanging ideas in the mailing lists and contributing code will (and already is). -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - 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: Discussion
On 22.12.2009 17:41, Alfonso Quiroga wrote: I agree with Thiago, but I've never used Wicket. I've used tapestry5 and I really like it. Both frameworks are component-based, maybe some day I'll try wicket. But if tap5 works for me... why do I have to discuss in server-side? I prefer to share my solutions and workarounds in this list, where there are people really interested in T5. I agree on the discussions. I think that (if needed) best promotion of Tapestry would be if everyone that is actually using it (and liking it) created a post somewhere or blogged about the reasons for choosing Tapestry and preferable to link such pages from the central documentation. The thing is that people who are new to all this, have to look somewhere and decide which technology to choose. There are not many comparisons where Tapestry is mentioned and most of them are not really favourable and mainly point out that Tapestry is too hard to learn. ... It is not. I was in this position two years ago, I had experience with Oracle Web PL/SQL and APEX, JSP, JSF, ASP and PHP and I am creating web sites from 1996 and I had the responsibility to choose something better. Even with such experience and even I was ready to learn from scratch it was hard to choose the technology for the next task. I decided to start with Tapestry bacause it was supposedly the hardest :)... It was not and it solved many problems I had with the others. smime.p7s Description: S/MIME Cryptographic Signature
Re: Discussion
Exactly ... I have yet to figure out why the Tapestry community as a whole is somewhat passive whereas other communities (such as Wicket and Rails) are extremely vocal. Out in the larger world, the best impression of Tapestry comes not from its creators, but from its users, and the users do not talk enough about Tapestry outside of these mailing lists. More blogging, please! On Tue, Dec 22, 2009 at 10:06 AM, Vangel V. Ajanovski a...@ii.edu.mk wrote: On 22.12.2009 17:41, Alfonso Quiroga wrote: I agree with Thiago, but I've never used Wicket. I've used tapestry5 and I really like it. Both frameworks are component-based, maybe some day I'll try wicket. But if tap5 works for me... why do I have to discuss in server-side? I prefer to share my solutions and workarounds in this list, where there are people really interested in T5. I agree on the discussions. I think that (if needed) best promotion of Tapestry would be if everyone that is actually using it (and liking it) created a post somewhere or blogged about the reasons for choosing Tapestry and preferable to link such pages from the central documentation. The thing is that people who are new to all this, have to look somewhere and decide which technology to choose. There are not many comparisons where Tapestry is mentioned and most of them are not really favourable and mainly point out that Tapestry is too hard to learn. ... It is not. I was in this position two years ago, I had experience with Oracle Web PL/SQL and APEX, JSP, JSF, ASP and PHP and I am creating web sites from 1996 and I had the responsibility to choose something better. Even with such experience and even I was ready to learn from scratch it was hard to choose the technology for the next task. I decided to start with Tapestry bacause it was supposedly the hardest :)... It was not and it solved many problems I had with the others. -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Discussion
I like to think that's because the Tapestry users are using Tapestry to be productive, instead of just talking about it making them productive. ;) But we could all certainly step our publicity up a bit. Cheers, Robert On Dec 22, 2009, at 12/221:21 PM , Howard Lewis Ship wrote: Exactly ... I have yet to figure out why the Tapestry community as a whole is somewhat passive whereas other communities (such as Wicket and Rails) are extremely vocal. Out in the larger world, the best impression of Tapestry comes not from its creators, but from its users, and the users do not talk enough about Tapestry outside of these mailing lists. More blogging, please! On Tue, Dec 22, 2009 at 10:06 AM, Vangel V. Ajanovski a...@ii.edu.mk wrote: On 22.12.2009 17:41, Alfonso Quiroga wrote: I agree with Thiago, but I've never used Wicket. I've used tapestry5 and I really like it. Both frameworks are component-based, maybe some day I'll try wicket. But if tap5 works for me... why do I have to discuss in server-side? I prefer to share my solutions and workarounds in this list, where there are people really interested in T5. I agree on the discussions. I think that (if needed) best promotion of Tapestry would be if everyone that is actually using it (and liking it) created a post somewhere or blogged about the reasons for choosing Tapestry and preferable to link such pages from the central documentation. The thing is that people who are new to all this, have to look somewhere and decide which technology to choose. There are not many comparisons where Tapestry is mentioned and most of them are not really favourable and mainly point out that Tapestry is too hard to learn. ... It is not. I was in this position two years ago, I had experience with Oracle Web PL/SQL and APEX, JSP, JSF, ASP and PHP and I am creating web sites from 1996 and I had the responsibility to choose something better. Even with such experience and even I was ready to learn from scratch it was hard to choose the technology for the next task. I decided to start with Tapestry bacause it was supposedly the hardest :)... It was not and it solved many problems I had with the others. -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - 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: Discussion
Robert, You need to be a Tapestry evangelist as well. Remember, Howard wants to make money- he wants to strike it rich. Please co-operate to make his dream come true. Don't be a free loader, man! On Tue, Dec 22, 2009 at 10:28 PM, Robert Zeigler robe...@scazdl.org wrote: I like to think that's because the Tapestry users are using Tapestry to be productive, instead of just talking about it making them productive. ;) But we could all certainly step our publicity up a bit. Cheers, Robert On Dec 22, 2009, at 12/221:21 PM , Howard Lewis Ship wrote: Exactly ... I have yet to figure out why the Tapestry community as a whole is somewhat passive whereas other communities (such as Wicket and Rails) are extremely vocal. Out in the larger world, the best impression of Tapestry comes not from its creators, but from its users, and the users do not talk enough about Tapestry outside of these mailing lists. More blogging, please! On Tue, Dec 22, 2009 at 10:06 AM, Vangel V. Ajanovski a...@ii.edu.mk wrote: On 22.12.2009 17:41, Alfonso Quiroga wrote: I agree with Thiago, but I've never used Wicket. I've used tapestry5 and I really like it. Both frameworks are component-based, maybe some day I'll try wicket. But if tap5 works for me... why do I have to discuss in server-side? I prefer to share my solutions and workarounds in this list, where there are people really interested in T5. I agree on the discussions. I think that (if needed) best promotion of Tapestry would be if everyone that is actually using it (and liking it) created a post somewhere or blogged about the reasons for choosing Tapestry and preferable to link such pages from the central documentation. The thing is that people who are new to all this, have to look somewhere and decide which technology to choose. There are not many comparisons where Tapestry is mentioned and most of them are not really favourable and mainly point out that Tapestry is too hard to learn. ... It is not. I was in this position two years ago, I had experience with Oracle Web PL/SQL and APEX, JSP, JSF, ASP and PHP and I am creating web sites from 1996 and I had the responsibility to choose something better. Even with such experience and even I was ready to learn from scratch it was hard to choose the technology for the next task. I decided to start with Tapestry bacause it was supposedly the hardest :)... It was not and it solved many problems I had with the others. -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - 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: Discussion
Em Tue, 22 Dec 2009 19:53:46 -0200, Gerald Bauer gtat...@gmail.com escreveu: Robert, You need to be a Tapestry evangelist as well. Remember, Howard wants to make money- he wants to strike it rich. Please co-operate to make his dream come true. Don't be a free loader, man! Gerald, I hope you're being sarcastic. Otherwise, as we say here in Brazil, you've just missed a good opportunity to remain silent. :) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: Discussion
I don't agree with the OP that the ServerSide discussion shows Tapestry has lost the battle - two posters state they don't want to see Tapestry mentioned. That's all there is. However, I can't agree with you Thiago. The old saying is if you say it enough times then people will believe it is true. If you are just going to stand by and let trolls post bad things about Tapestry unchallenged then they have won the argument - regardless of how bad their argument may be and how incorrect their views may be. After all, someone pitching up and wanting a framework will read what they've written and believe it. Who is to say these anti-Tapestry people are wrong? Not you - because you won't counter their arguments! :-) Sure - don't feed the trolls. But all that is necessary is to say something positive; not engage them in an argument. Merry Xmas everyone. -Original Message- From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com] Sent: 22 December 2009 15:26 To: Tapestry users Subject: Re: Discussion Em Tue, 22 Dec 2009 12:45:20 -0200, Banchi Liko banchi...@gmail.com escreveu: Hi guys, Hi! There is a discussion going on here http://www.theserverside.com/news/thread.tss?thread_id=58858 and seems like Tapestry ihas already been ruled out as a viable and serious web framework. TheServerSide comments has too many trolls to have a good, reasonable discussion there. Wicket seems to be the favorite. Some people who bother to post there like Wicket. Most people who like Tapestry, maybe all of them, don't bother to post there. I'm sad Tapestry has lost the battle and afraid it might die soon. Please source or explain your statements or you'll be treated like a troll here. Please go and contribute and let your voice be heard before Tapestry dies a horrible death. No, thank you. Posting there will not change Tapestry's fate. Using it, exchanging ideas in the mailing lists and contributing code will (and already is). -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - 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
discussion: why-did-you-stop-using-tapestry
I think it would be interesting for us to read this discussion, just to concentrate again on what can be improved in T5. Also good comments can help the public image of T5. http://stackoverflow.com/questions/1303438/why-did-you-stop-using-tapestry - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: discussion: why-did-you-stop-using-tapestry
Em Wed, 02 Sep 2009 05:12:10 -0300, Sergey Didenko sergey.dide...@gmail.com escreveu: I think it would be interesting for us to read this discussion, just to concentrate again on what can be improved in T5. Also good comments can help the public image of T5. http://stackoverflow.com/questions/1303438/why-did-you-stop-using-tapestry The first comment has some good points, but that guy is a little bit trollish. Some of his points are about Tapestry 4, not 5. I wrote a little rebuttal there. -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
[ANN] Tapestry5-book discussion group created
In order to take the discussion about the proposed Tapestry 5 community book off the T5 user list, I've created a group on the topic . I've sent invitations to most (if not all) people who have expressed an interest in contributing, if you haven't received such an invitation, please visit the group (at http://groups.google.com/group/*tapestry5-book*http://groups.google.com/group/tapestry5-book) or send me an email and I'll send an invite. Just as a reminder, the project is currently on Google code at http://code.google.com/p/tapestry5-book .
Moving this discussion group
Hi All, I was wondering if people would like to move this discussion group to a different groups service, like Google groups. I suggest Google groups because it seems like many of the 'regulars' in this discussion forum have GMail accounts. Personally I like Google groups because the user interface is easy to use, but would not mind other services like Yahoo's; anything but this current email-based system (how archaic!). It seems that someone has already started a tapestry group: http://groups.google.com/group/tapestry If you wouldn't mind, please check it out (and join). Sincerely, Daniel Trebbien. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving this discussion group
Its a recurring question, but people seem to like it, and if you prefer newsgroups you can use gmane like I do. Daniel Trebbien [EMAIL PROTECTED] skrev i en meddelelse news:[EMAIL PROTECTED] Hi All, I was wondering if people would like to move this discussion group to a different groups service, like Google groups. I suggest Google groups because it seems like many of the 'regulars' in this discussion forum have GMail accounts. Personally I like Google groups because the user interface is easy to use, but would not mind other services like Yahoo's; anything but this current email-based system (how archaic!). It seems that someone has already started a tapestry group: http://groups.google.com/group/tapestry If you wouldn't mind, please check it out (and join). Sincerely, Daniel Trebbien. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving this discussion group
I recommend Nabble to track this list's activity: http://www.nabble.com On 7/31/06, hv @ Fashion Content [EMAIL PROTECTED] wrote: Its a recurring question, but people seem to like it, and if you prefer newsgroups you can use gmane like I do. Daniel Trebbien [EMAIL PROTECTED] skrev i en meddelelse news:[EMAIL PROTECTED] Hi All, I was wondering if people would like to move this discussion group to a different groups service, like Google groups. I suggest Google groups because it seems like many of the 'regulars' in this discussion forum have GMail accounts. Personally I like Google groups because the user interface is easy to use, but would not mind other services like Yahoo's; anything but this current email-based system (how archaic!). It seems that someone has already started a tapestry group: http://groups.google.com/group/tapestry If you wouldn't mind, please check it out (and join). Sincerely, Daniel Trebbien. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cumprimentos, Rui Pacheco