Re: [Informal poll] Version number for Jakarta EE-supporting Tapestry version
Hello All, We had the same idea about adding a classifier or altering the maven coordinates. What we found is that adding "-jakarata" to the artifact names worked extremely well and required very minimal changes to the Tapestry 5 gradle build. One benefit of this approach is that we were able to use the same version number for both javax and jakarta artifacts since they effectively have separate namespaces. We also investigated the classifiers approach, but abandoned that idea quickly since it required much more extensive project changes. We also ran into major problems with IntelliJ's handling of source and javadoc archives with another library that went down that path (Apache Shiro IIRC). In that case, they used a transform to generate the jakarta artifacts from the javax artifacts. The net effect was that the IDE was confused by the classifiers and selected the wrong sources and javadoc archives. FYI - On a related note, we have been tracking changes to the master branch for our jakarata build, and encountered a runtime breakage in some of the recent changes (~ 3 weeks ago). The errors we encountered were of the of form "Exception assembling embedded component...". We were very pressed for time when this happened, and have not had time to track down the root cause. I read somewhere that this was a known issue to be fixed in 5.8.7. Regards, David On 8/7/2024 2:40 PM, Dmitry Gusev wrote: Hi Thiago, Just a thought, but did you consider to have a `jakarta` word somewhere in the artifact coordinates? Either in the artifact names or as a classifier in the versions. This way we could still have release numbers continue naturally and let the users pick the flavor. We can eventually stop producing non-jakarta flavors when time comes, if ever, or do javax/jakarta-only fixes if necessary skipping the flavors where it would make sense. Having holes (regardless how big or small they are) in version numbers will break semver and tooling that rely on its conventions potentially. Regards, Dmitry On Wednesday, July 31, 2024, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: Hello, Tapestry community! As already discussed, the Jakarta EE an javax.servlet versions of the Servlet API have some differences that go beyond the package rename, but, at the same time, the Tapestry team won't leave the javax.servlet users behind. We'll have 2 different branches, master on Jakarta EE) and javax, and we'll keep them in feature parity as much as possible (of course, Jakarta EE is the living API, while javax.servlet is dead, so any future Tapestry feature that depends on something Jakarta EE has but javax.servlet doesn't won't be backported to the javax branch). With the approach decided, we arrive at a problem similar to what same say is the most difficult one in software development: naming things. Current Tapestry is at version 5.8.6. What should be the version number for the upcoming Jakarta EE-supporting version? I'd like to remind everyone that the project itself is Tapestry 5, given it's a complete rewrite that shares no code with Tapestry 4 and other previous versions, so, for example, version 5.8.6 should actually be considered version 8.6 of Tapestry 5. The Tapestry team has come up with some suggestions: * 5.50: Pros: 50 is a round number, half of 100, a lot larger than 8, so we have a lot of room for new Tapestry major releases of the javax branch to be 5.9.x, 5.10.x, etc. Con: no easy association between javax and Jakarta version. * 5.19: Pros: 9 is the Jakarta EE version containing the Servlet API version with the jakarta.servlet package used by Tapestry in the branch that supports it. While it doesn't leave as much room for new major releases of the javax branch, it does leave a good number. Con: no easy association between javax and Jakarta version. * 5.18: Pro: easy association between versions of javax and Jakarta branches, which would be kept in a constant version difference. We could even have the first Jakarta release to be 5.18.7 while the javax release would be 5.8.7 (we're planning to release it in the upcoming weeks). Con: less room for major releases. * 5.28: Mostly same as above, but with larger room for major releases. * 5.9: Pro: matches the Jakarta EE version. Cons: no room for major releases at all. (Me, Thiago, really dislike this idea, but another committer suggested it and really loves it, so here it is, hehehe). * Something else you suggest (with rationale, please). There's no perfect solution. All of them come with a bit of confusion. I personally would go with either 5.18 or 5.28 and have the first release being 5.18.7 or 5.28.7 to align with the upcoming 5.8.7 release. I'm looking forward to your feedback. Cheers! -- Thiago H. de Paula Figueiredo - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.a
Re: [ANNOUNCEMENT] Tapestry 5.8.4 release
First, thanks for the 5.8.4 release! The timing was perfect since underscore.js was one of the items flagged in a recent vulnerability scan. I am also very interested in the Jakarata EE migration. We are currently in the process of upgrading to Spring Boot 3.2 since support for 2.7 ended in November 2023. Given there is no schedule for official Tapestry Jakarta EE support, we decided to create and host an internal build of Tapestry. I applied the changes provided by Christian Köberl in pull request TAP5-2741 to the 5.8.4 sources and everything is looking good so far. Thank you so much for providing the pull request! We initially considered publishing the Tapestry jars with a classifier of "jakarta" similar to other projects, but that required substantial changes to the build. Instead, we made a few small changes to the build to publish the Tapestry artifacts with a Maven group Id of *org.apache.tapestry-jakarta*. That approach was much simpler and avoids the collision with the non-jakarta artifacts. I would be very interested in everyone's thoughts on how the official Jakarta EE support should work. Perhaps it would be feasible to create an automated patch and build process that can be maintained in parallel to the official Tapestry build? While it may not be as elegant as a fully integrated approach, I believe it would address the immediate need for Jakarta EE artifacts without significantly increasing the maintenance costs. Thoughts? Best Regards, David Taylor On 2/13/2024 8:00 AM, Thiago H. de Paula Figueiredo wrote: On Tue, Feb 13, 2024 at 8:20 AM Carlos Montero Canabal wrote: Good job Tapestry Team, congratulations! Thanks! I have a question. This release supports Java 21 but checking Tomcat versions (https://tomcat.apache.org/whichversion.html), If I want to use Java 21 I have to use Tomcat 11.0.X and this version requires servlet spec 6.1. From the 6.0 version, servlet is provided by jakarta and all package names switch from javax.servlet to jakarta.servlet. Any updates about migrating tapestry code from javax to jakarta? We won't provide any schedule, but indeed our main priority now is to provide a Tapestry version using the jakarta.* packages and Servlet API 6. Cheers! -- Thiago H. de Paula Figueiredo - To unsubscribe, e-mail:users-unsubscr...@tapestry.apache.org For additional commands, e-mail:users-h...@tapestry.apache.org
Re: Tapestry and Typescript
Hi Ben, Have you considered using Graal Javascript in place of Rhino? It implements the latest ECMAScript spec and also runs nicely on a plain Java 8 VM with minimal dependencies. We have been using Graal for advanced scripting features in our product and are very happy with the fit and finish. The only thing custom we had to develop was an in-memory filesystem implementation to avoid storing files on disk. Regards, David emailsig On 9/2/2021 4:42 AM, Ben Weidig wrote: Hi Jonathan, just FYI, I've created an issue for updating Rhino and adding a possibility to configure it. https://issues.apache.org/jira/browse/TAP5-2691 Cheers, Ben On Thu, Sep 2, 2021 at 10:26 AM Jonathan Luke Shearman wrote: Hi Ben, Thanks for your reply and ideas! I did try updating Rhino to the latest version - but it didn't fix the issue directly, I think to take advantage of the newer features an ES6 version flag has to be set, and I haven't had time to try and override that in the tapestry implementation yet. I'll try out the ResourceTransformer option, maybe that will be easier to maintain. Cheers, Jonathan -Original Message- From: Ben Weidig Sent: Wednesday, 1 September 2021 10:52 AM To: Tapestry users Subject: Re: Tapestry and Typescript Hi Jonathan, I haven't worked with TS in 5.7.2 so far, but I tried to look into it. The two issues on Rhino's Github are not very helpful... https://github.com/mozilla/rhino/issues/658 (solved itself somehow) https://github.com/mozilla/rhino/issues/430 (solved with newer Rhino version) Tapestry uses an older Rhino version, have you tried to using the latest one? Not sure if it's compatible though without changes in Tapestry itself, though. Another option would be writing your own ResourceTransformer to compile Typescript yourself using a local TSC instead of typescript.js with Rhino. Maybe someone else has an idea how to integrate Webpack, our JS-setup is rather simple. Cheers, Ben On Wed, Sep 1, 2021 at 9:01 AM Jonathan Luke Shearman wrote: Hello, First post here and I have a feeling it may not be Tapestry related but wanted to reach out here just in case! I recently joined a project that has been maintained for a few years and is currently using Tapestry 5.7.2 Tasked with upgrading some frontend components, I wanted to use typescript and got it running using the setup in tapestry-webresources using the Rhino library. This worked great on my machine and on the web server, but in the last week some colleagues needed to work on the same code and discovered that typescript wasn’t getting transpiled on their local setup. Rhino complains about a “missing name after the . operator” but references the typescript.js file at line 1467 (exception at the end of this message) – ie the file used to transpile the other .ts files as far as I’ve understood. ( Please correct me if I’m mistaken) I’ve tested this on 8 different colleague machines with only a 50% success rate unfortunately. We are all running what should be identical setups, so it’s quite confusing why some don’t work. It doesn’t seem to depend on node or tsc command line tools, and Looking into it, I’m thinking it’s some sort of file reading issue – there are similar issues on Rhino’s github but unresolved there too. A suggested fix was to change every someObject.delete to someObject[‘delete’] but I don’t think editing typescript.js is the right solution here. The error comes from ‘delete’ being a reserved word in javascript, and so this is most probably an issue with Rhino’s javascript parser. I wondered if anyone has ever come across this issue before or might have some better ideas on what else to check? And just as more general question – can anyone recommend a better setup for handling typescript in Tapestry? My next goal is to bring in npm packages and potentially work on replacing requireJS with something like webpack, but I’ve seen on previous threads here that there’s been limited success? I’ve been considering running npm scripts at Tapestry build time to ‘pre-compile’ all the frontend code in a separate directory and then hand it back to requireJS by dumping the javascript files into /modules.. but that feels like overkill. I’d appreciate any ideas people might have, happy to test anything out at this point. Cheers, Jonathan Original Exception: Exception: org.apache.tapestry5.ioc.internal.OperationException Message: missing name after . operator (classpath:org/apache/tapestry5/webresources/internal/typescript.js#14 67) trace: Streaming compressed module custom-file Streaming classpath:META-INF/modules/custom-file.ts (compressed) Compiling classpath:META-INF/modules/custom-file.ts from TS to JavaScript Creating Rhino executor for source(s) classpath:org/apache/tapestry5/webresources/internal/typescript.js, classpath:org/apache/tapestry5/webresources/internal/invoke-ty
Re: Tapestry Jumpstart site is down
Thanks Geoff. I hope you are doing well. Some crazy times. David On 4/15/2020 12:04 AM, JumpStart wrote: Very good question. I’ll see if I can get it up again shortly. Geoff On 15 Apr 2020, at 12:02 pm, David Taylor wrote: Hi! Search Results Web results I noticed Geoff's Tapestry Jumpstart site has been down for the last few days. DNS is still resolving, but the server responds with a connection timeout. Does anyone know what happened to the site? Thanks, David - 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
Tapestry Jumpstart site is down
Hi! Search Results Web results I noticed Geoff's Tapestry Jumpstart site has been down for the last few days. DNS is still resolving, but the server responds with a connection timeout. Does anyone know what happened to the site? Thanks, David - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry 5.5 progress
Hello everyone and Happy New Year! Just following up to see where we are at with testing of 5.5-beta-3. We are testing using a private build from master to pickup the recent changes and have not run into any compatibility issues so far. I am curious whether anyone has run into any show stoppers? Assuming there are no blocking issues, what is the next step forward with 5.5? Regards, David On 6/18/2019 8:46 AM, Thiago H. de Paula Figueiredo wrote: On Thu, Jun 13, 2019 at 5:04 PM David Taylor wrote: Hello, Hi! Does anyone know where we stand on the Tapestry 5.5 release? We should get a release in the upcoming months. Are there specific blocking issues that need to be addressed? I recall seeing one related to Java 11 and ASM, but it is not clear if that is being worked on at the moment. It was worked and it's already working, except for one specific case I'm planning to fix this weekend (overriding of interface default methods). We are working on upgrading our applications to Java 11 and may be able to help with troubleshooting of open issues. Awesome! Please post any issues you find with Tapestry both here and in Jira so we can properly track and fix them. Regards, David - 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
Tapestry 5.5 progress
Hello, Does anyone know where we stand on the Tapestry 5.5 release? Are there specific blocking issues that need to be addressed? I recall seeing one related to Java 11 and ASM, but it is not clear if that is being worked on at the moment. We are working on upgrading our applications to Java 11 and may be able to help with troubleshooting of open issues. Regards, David - 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: 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: [ANNOUNCEMENT] Tapestry 5.4.4
It would be great to see a fresh vision and roadmap for Tapestry going forward. Tapestry has many strengths, but has a relatively steep learning curve and does not do enough to help new developers get off the ground. We have been using Tapestry for a very long time and still find it challenging at times, especially when integrating Tapestry with newer client-side technologies. I saw your mention of bootique-tapestry and am curious how that is working out? We briefly looked at bootique-tapestry, but decided to create a module to integrate with Spring Boot instead. Spring Boot won out mostly because of the breadth of what it has to offer and the large user community. There are still a few rough spots in our Spring Boot integration, but the effort was very worthwhile. The combination of Gradle + Spring Boot + Tapestry is very powerful and greatly reduces the amount of boilerplate needed to create a production ready application. The integration with Spring Boot is surprisingly thin and the integration is nearly seamless. Anyone have a sense as to whether the community is interested in pursuing a first-class Spring Boot integration? I would be happy to share what we have done if there is real interest in making it a proper Tapestry feature. I don't think it would be a huge effort if some of the core Tapestry developers were engaged in the process. Having a supported integration with Spring Boot might bring much deserved attention and new users to Tapestry. Regards, David Congratulations! Thanks to the core team for your continuous work and the effort you put into maintaining Tapestry. I think the whole industry goes the way of trying to simplify things (just take a look at the most recent programming languages & frameworks). If we’re talking about modernizing and competing with other frameworks, I would like to see Tapestry reducing the complexity that is currently required to grasp the framework and its various concepts (which are technically great, but sometimes hard to understand if you just start working with Tapestry). I think this will only work by providing old & new APIs at the same time and by making the upgrade path and improvements very clear in the documentation. Personally I’m also getting into the vibe of smaller services that communicate with each other, instead of this one monolithic giant that tries to be everything, but is nothing in the end. We use bootique-tapestry (and also other Bootique-compatible integrations). I would like to see Tapestry to also go in this direction and improve integration on similar deployment environments. On the other side, I’m currently pretty happy with the state of Tapestry and with the framework keeping up with modern Java versions. Best, Rafael On 2018-19-12, at 11:02 AM, Christopher Dodunski wrote: Good team effort! It's encouraging to see Tapestry progressing in step with associated technologies: Java 12 is due out in March, and Hibernate currently at version 5.3.3. Tapestry 5 was a leap forward from 4. Where does the community see Tapestry 6 at on the Java web landscape? A free and frank conversation - Tapestry's strengths and weaknesses, what attracts others to JSF, Wicket and other competing frameworks, where web frameworks are generally headed, etcetera - ought to help ensure that Tapestry remains relevant beyond 2020. Regards, Chris. - 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: Tapestry 5.3.7 with Tanuki service wrapper
We use JSW (last non-GPL version) + Jetty 9.3/Tomcat 8 + Tapestry 5.4 in production on various flavors of Windows without issue. The only unusual thing I have seen is a problem with HikariCP having problems locating the jTDS driver at system startup. Very weird since the problem does not occur if the server is manually restarted. The fix was to tell HikariCP the fully qualified class name of the driver. David emailsig On 3/29/2016 3:42 AM, Qbyte Consulting wrote: Hi, Has anyone had success running ioc via the Tanuki Service Wrapper product? I'm having problems with Tapestry instantiating a DAO service that is injected with EntityManager references. Suspect a class loader problem, I'm getting inconsistent results. All works fine from the command line launch? Probably means this isn't a Tapestry issue, but just interested to know anyone who's had a good result with Tanuki starting Tapestry? John - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry is a sinking Ship
If Tapestry is so terrible, why waste all the energy? Just to be obnoxious? We would abandon Tapestry tomorrow if it weren't so bloody fast and easy to extend. emailsig On 2/12/2016 3:53 PM, Thiago H de Paula Figueiredo wrote: On Fri, 12 Feb 2016 17:19:28 -0200, Emmanuel Sowah wrote: Hi Tapestry sect, The state of Tapestry now is very bad, as Howard and all the other commiters have abandoned it. This is not true. Just check Jira and the Git logs. Even Thiago has secretly abandoned Tapestry. I have not, and you're telling a lie. I'm just answering this troll because of the lies he keeps on spreading, which are bordering on defamation. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Attribute namespace prefix usage
Hi Cezary, Thanks for the clarification. I was aware of the problem with id and name values related to loops and forms, but did not have a detailed picture as to how Tapestry uses "id" and "t:id" in that scenario. The same applies to the "name" attribute handling, but we have not yet had a need to open that can of worms. As an aside, the context of my question is related to work we are doing to create a hybrid Tapestry / SPA architecture. Getting the two paradigms to integrate seamlessly has been an interesting and challenging adventure. Hopefully, Tapestry will be moving more that direction in the future since client-side technologies are evolving rapidly and here to stay. Thanks, David emailsig On 11/23/2015 3:00 PM, Cezary Biernacki wrote: Hi David, Regarding your point 1). "t:id" is quite different than "id". "t:id" is used to map component definitions in templates to component injections in Java classes. "id" (without namespace) is HTML "id" attribute, and while often Tapestry generates "id" that is equal to "t:id", it is not always true (IIRC, e.g. when component is used multiple times on the page, or when response is generated for Ajax request). Another difference is that "t:id" must be also constant, while "id" can be dynamically generated. Use "t:id" when you want to refer to your components in Java code (plus from some other components, e.g. in Label's "for" attribute). Use "id" when you want to force some particular "id" value in the generated HTML, but watch for cases when it is component that might be included multiple times on a page, in loops or in AJAX responses. Best regards, Cezary On Mon, Nov 23, 2015 at 7:51 PM, David Taylor wrote: Hello, I am working on a custom component library and have observed some unexpected behavior regarding attribute namespace prefix usage. Can someone please clarify the official Tapestry rules regarding the usage of component attribute namespace prefixes? Here are two scenarios that I believe get to the crux of the question: 1) Component id attributes (t:id="..." v.s. id="...") I have been happily using t:id="" in my templates, but found that Tapestry will not accept values that are not valid Java identifiers. This is very inconvenient since we are creating a wrapper for an ajax widget set that uses hyphenated names. What I have found is that using the "id" attribute without a prefix works: This fails since "my-button" is not a valid Java identifier: This succeeds (without the "t:" prefix) and works as expected. For reference, our custom components implement the ClientElement interface and use the JavaScriptSupport. allocateClientId(...) method to get the client element Id from the template. I have not yet traced into the Tapestry code, but it also appears that "id" attribute values (without the t: prefix) are being mapped to equivalent camel-case Java-compatible identifiers. This behavior makes sense since the HTML 5 DOM reportedly uses a similar attribute mapping scheme: http://stackoverflow.com/questions/20985204/does-jquery-internaly-converts-html5-data-attribute-keys-to-lowercase 2) Omitting the t: attribute prefix seems to work except for t:mixins=". . ." I have found through empirical evidence that I can omit the "t:" attribute prefix when configuring custom components in templates. The one exception seems to be t:mixins=". . .", which appears to be ignored if the prefix is omitted: This succeeds and applies the mixin to the component: This is accepted, but does not apply the mixin to the component: Is the ability to omit the namespace prefix an intentional feature, or a side effect of the way templates are being parsed? I am unclear on the expected Tapestry behavior. My original understanding was that attributes matching declared component properties would behave the way the mixins attribute is working. Being able to omit the prefix is nice, but I don't want to depend on a feature that is not officially supported. Thanks, David - 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
Attribute namespace prefix usage
Hello, I am working on a custom component library and have observed some unexpected behavior regarding attribute namespace prefix usage. Can someone please clarify the official Tapestry rules regarding the usage of component attribute namespace prefixes? Here are two scenarios that I believe get to the crux of the question: 1) Component id attributes (t:id="..." v.s. id="...") I have been happily using t:id="" in my templates, but found that Tapestry will not accept values that are not valid Java identifiers. This is very inconvenient since we are creating a wrapper for an ajax widget set that uses hyphenated names. What I have found is that using the "id" attribute without a prefix works: This fails since "my-button" is not a valid Java identifier: This succeeds (without the "t:" prefix) and works as expected. For reference, our custom components implement the ClientElement interface and use the JavaScriptSupport. allocateClientId(...) method to get the client element Id from the template. I have not yet traced into the Tapestry code, but it also appears that "id" attribute values (without the t: prefix) are being mapped to equivalent camel-case Java-compatible identifiers. This behavior makes sense since the HTML 5 DOM reportedly uses a similar attribute mapping scheme: http://stackoverflow.com/questions/20985204/does-jquery-internaly-converts-html5-data-attribute-keys-to-lowercase 2) Omitting the t: attribute prefix seems to work except for t:mixins=". . ." I have found through empirical evidence that I can omit the "t:" attribute prefix when configuring custom components in templates. The one exception seems to be t:mixins=". . .", which appears to be ignored if the prefix is omitted: This succeeds and applies the mixin to the component: This is accepted, but does not apply the mixin to the component: Is the ability to omit the namespace prefix an intentional feature, or a side effect of the way templates are being parsed? I am unclear on the expected Tapestry behavior. My original understanding was that attributes matching declared component properties would behave the way the mixins attribute is working. Being able to omit the prefix is nice, but I don't want to depend on a feature that is not officially supported. Thanks, David - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
