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.
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. 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. On Tue, Jul 18, 2017 at 4:03 AM, Yasser Zamani <yasser.zam...@live.com> wrote: > Great! Happy that I know these now! > > Are we, volunteers, allowed to help/contribute with such structural > changes? I hope yes. If so, I have passion in `support for > actors/asynchronous request handling`. Could you please register an > issue with a few directive details? then we can pick and start work on > that :) same ones for `less static util classes and coupled code` step > by step. (`make JSON plugin more configurable` is simple to pick, while > already has issues; `improve the framework's security` is also clear > enough to being considered by us). > > Ton of thanks for your time and writing for us! > > On 7/18/2017 10:37 AM, Lukasz Lenart wrote: > > 2017-07-17 10:49 GMT+02:00 Yasser Zamani <yasser.zam...@live.com>: > >> Absolutely, I did not mean you yourself should do or did something :) I > >> just asked these to know if me/we, contributors, should just wait for > >> user's demands in jira. or no, it's needed to analysis, study and discus > >> competitors here, for new applicable (not all) features or improvements > >> in Struts (e.g. you informed me that JSON and Angular are reasons so I > >> can study them if any applicable feature could be added to S2). > > > > No, we should definitely not sit and wait :) Rather figure out what > > should be improved and what new features would be nice to have - and > > then code and implement them :) > > > > My two new features on the radar: > > - make JSON plugin more configurable, there are few issues related to it > [1] > > - add support for actors/asynchronous request handling > > > > Besides these, my main goal is to improve the framework's security and > > flexibility (less static util classes and coupled code). > > > > [1] https://issues.apache.org/jira/issues/?jql=component%20% > 3D%20%22Plugin%20-%20JSON%22%20AND%20project%20%3D%20WW% > 20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC > > > > > > Regards > > > -- Sent from my C64 using a 300 baud modem
