Hello, I kind of agree with Rafael. I would really like to see tapestry core having no css or JS framework dependencies at all, server side only validation etc… And a pluggable architecture where you can add bootstrap compatibility os JS frameworks or form client side validation etc…
The ability to start with a blank page, nothing in it added by Tapestry, and then the ability to progressively add stuff in the head or in the footer etc.. I don’t always want tapestry to render doctype or head tag etc… I know you can change everything by contributing configurations, but most of the time I need to remove/override contributions. I don’t want bootstrap, I don’t want Jquery. I want a custom doctype, head etc… Now the web development is more focused on the client, you write more JS than before, in the typical setup you would use webpack to compress js and minify scss, web components with React, Amber etc... With Tapestry you need to understand the internals to know what to remove or to add. Forms could be simplified, it’s one of the most complex Tapestry concept, because all other concepts are very straight forward and easy to grab. Form validation should always be expressed as simple data attributes per field or globally at the form tag level (that’s partially like this). Then you can contribute or mixin any type of validators or use custom js to parse your form. This would work great with loops, partial form or dynamic form rendering should be improved. Some other areas could also be simplified like links, activation context etc… Most of the people I explain tapestry to never understand why there are so many different types of links. Users want a link to a page, that eventually calls a listener with parameters and most of the time they prefer named parameters. I think there should be only one type of link with configurable options and good default values (optional page name, optional listener name, optional named parameters etc…) I would be very interested to hear Wicket users on why they prefer Wicket to Tapestry or which Wicket features they prefer. From my experience JSF is mostly used because it’s supported by big vendors, and you can start from a blank page with minimal dependencies if needed. Grails is pretty neat because it generates quite a lot of things for you, and it’s easy to use but it’s less powerful than tapestry in some aspects. Play like Grails has a command line generator that builds most of the skeleton for you, you just need to fill the “placeholders”, they all borrow concepts from rails. I think Tapestry is in between: in some aspects it includes too many features on others not enough. We should split tapestry in smaller pieces, and have a command line tool to generate all necessary parts of an application (web page, api/json endpoint, validator, type coercer, model etc..). This has already been done in the past but that could be improved. Just my two cents :) Numa > Le 19 déc. 2018 à 19:01, Thiago H. de Paula Figueiredo <thiag...@gmail.com> a > écrit : > > On Wed, Dec 19, 2018 at 2:03 PM Rafael Bugajewski <raf...@juicycocktail.com> > wrote: > >> The one thing that comes straight up from my head is the current >> complexity / pipeline necessary for generating output. A couple of months >> ago I wanted to generate valid AMP pages within Tapestry. After one day of >> research and a non-working proof of concept, I decided to use the Play >> framework for this small customer and it worked right away. Tapestry does >> some processing (necessary for other parts of the framework, AFAIK) that >> makes it hard to generate valid AMP pages. I would really love to use >> Tapestry here, and I don’t think it’s out of scope for the framework. >> > > What issue, exactly? Exact HTML output? If yes, this is something that > probably can be either fixed in Tapestry itself or customized implementing > a MarkupRenderer. > > >> >> Best, >> Rafael >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > -- > Thiago --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
