I read through some of the documents you mentioned, but not all yet. I'm thinking there is an elegant solution to this, but I'm not seeing it at the moment.
But, I do see the idea that you need to pass variables through to the application (somehow). So, the question is: how to do this best without breaking existing programs.... Maybe a small test case / POC would help to define the problem more clearly?! ~Roger -----Original Message----- From: Sandro Martini [mailto:sandro.mart...@gmail.com] Sent: Thursday, October 10, 2013 7:14 AM To: Developers - Apache Pivot Subject: Re: Inject properties in Application Hi all, no comments ? Bye 2013/10/8 Sandro Martini <sandro.mart...@gmail.com>: > Hi, > ok, I'll try to better explain my requirements here, if it's not > enough clear tell me :-) ... > > As starting point, look here: > http://svn.codespot.com/a/apache-extras.org/pivot-stuff/trunk/pivot-st > uff-common-groovy/test/pivot_stuff/common_groovy/ > all .gsh files are Groovy Scripts (they could be .groovy, but I rename > to .gsh to be more clear that they are scripts), and they use some > Groovy code (in some case inside the script, in others external in > .groovy classes just for convenience). > And of course Groovy code there extends Pivot Java code ... > To run examples you can find Windows batch files here: > http://svn.codespot.com/a/apache-extras.org/pivot-stuff/trunk/pivot-st > uff-common-groovy/_scripts/ > > The concept is similar to this: > http://groovy.codehaus.org/Scripts+and+Classes > > Use Case 1: > a Groovy/Java/Scala/etc application that executes a script, for simple > (or user-written) things ... but for this probably all is ok (no > changes required). > > Use Case 2: > a Groovy (soon Scala) Script that calls Groovy/Java code, and in that > script I could define variables/objects (like an external > environment), and currently I'm not able to pass to the application > unless I use some singleton trick. > Generally speaking I don't like too much the all-singleton approach > ... in a world evolving much more in multi-core/multi-thread (and > hard-to-do-well and not-too-much-unnecessary-synchronization) this is > a good reason to me. > But if for all us this is enough I can live with it :-) ... > > This is a field where I'd like to push Pivot: > http://www.reactivemanifesto.org/ > but could be for a long-term roadmap ... I'll post some idea later on > this (many of us know that I'm a big fan of Scala and related > products) because it's a big thing, and not strictly related to this. > > >> I'm thinking that for 2.1 could be useful to have a way to inject >> data inside Applications, for example have some variable (like a >> Classloader and maybe others) in a script and inject (or even set by >> hand) in the Application. >> But of course this requires a little update in that API, like add a >> method setExternalProperties(Map <String, Object> properties) or >> similar ... and let Applications implement it if needed (or use the >> empty version in Application.Adapter) ... > in this way we could be able to define objects from "outside" and set > in Pivot Application, but of course we should create an instance of > Application (custom, or Application.Adappter), and then set in it all > desired values. > >> Then, DesktopApplicationContext currently uses a Class instance of >> Application (dynamically loading the class instance), so maybe we >> could even add a method to get an Application instance already created ... > Here we could add a startup flag that when given (not sure if it's the > best way, I have to check this), the Application class instance is > taken from the externalProperties Map (if found) and used instead of > dynamically load it by name, so this small change should only be an > addition, reusing existing methods. > The problem here could be that Application instance should not be > already started (but writing in JavaDoc should be enough) ... so the > only other problem I see here could be a malicious injection from > "outside" in Application, but I don't think this could be a real > problem because it's up to the developer to use them. > > > What do you think ? > > Bye, > Sandro
