>From: Ken McWilliams <ken.mcwilli...@gmail.com> >Sent: Wednesday, July 19, 2017 5:55 AM >To: Struts Developers List <dev@struts.apache.org> >Subject: Re: Would we need to achieve better place in trends ranking? > >Lukasz it's good to hear the JSON plugin is on the horizon. For my own work I >created a new JSON Result type using FlexJson, for some reason I liked it >better >when serializing JPA Entities, it will by default serialize primitive types on >the >object but will not travel the graph unless you explicitly tell it the >collections to >traverse. Because it was the business of the action to fetch what was needed >(so >it knew what needed to be >returned) there was no issue specifying these strings. Each action had an >instance >of the JSON Serializer, along with a getter for it. After setting it the way I >wanted, >the result just fetched the configured instance from the action it self. It >didn't >have any pretty annotations or anything but it was mindlessly simple to >configure >and using the object that performed the Json serialization directly was very >convenient.
Hi Ken, I hope this mail finds you well :) I forgot back to you that Struts since 2.5.14 now is able to use not only FlexJson but also any customer specified JSON library. Please see [1] and feel free for any further comments. Please follow inline comments below.... > >Yasser get the code and start making changes... no harm in doing that. I've >never >seen anything but reasonableness from the struts developers if they like the >change and it won't break things for others I'm sure they'll be happy to have >more >people on team struts. > >MORE LESS OFF TOPIC >Regarding keeping up with the competition: I've started a project with Spark >framework [sparkjava.com]. It is a pretty cool framework. Struts and Spring and >many others are in a certain vein, this thing feels a lot more like >development in >Python, PHP, having a functional/imperative programming feel rather than an OO >one... It is pretty refreshing to hardly be required to create any objects. My >motivation was to use Dagger2 for DI, which does not work well with JEE (in a >container environment). Dagger2 needs to be able to travel the whole graph so >it >can't tolerate any "magic", other systems performing DI/reflective magic or >even >using external configuration, like an xml file to determine what to >instantiate, so >that eliminates a lot of web frameworks. It could still be made to work, but it >would have to start over at each point it couldn't trace, and _you_ would have >to >identify those points and work around that. All in all, not very practical. Thanks a lot! I probed both sparkjava and dagger2 on internet via googling "sparkjava vs spring boot" and "dagger 2 vs spring" and reading some articles. I can conclude them that it seems sparkjava is best when you want to learn then build a "not-enterprise" web app fast. Struts but somehow is for enterprise and heavy wen apps. However, I agree that sparkjava's "microservices" concept must be added to our Struts "probe and implement" plan, thank you. I found dagger2 best when there are limited resources and we need an urgent performance e.g. in mobile devices. But Struts unfortunately is not able to be used in mobile app developments so we can postpone dagger 2 to when Struts will be able. > >Any ways this thing is very different from the Java frameworks I've seen, it's >really >simple, it really seems like what is going on in a lot of other languages. >Really at >this point I don't know what it could bring to struts2... like adding a whole >functional API to struts would probably be too radical. > @dev wdyt? I thought what about add integration with front-end trends e.g. React, Angular, Vu.js, Node.js? and improve Struts internals with concept trends e.g. microservices, DIs and etc? I think these will "make Struts great again" :] And make us also with Struts :) Kind Regards.
