Leszek Gawron wrote:
I'm not advising that also. I am talking about providing an easy framework for
database operations that would be available from flow.
I had thought about this for a while... a lightweight JDBC wrapper for the Flow.
Then I thought about it more... although it might encourage people to start writing more things in Flowscript, I think the Correct Way(tm) would be to write your business logic in a real Java class and access it from the Flow that way.
Remember, the Flow is just for controlling the application. I suppose then the question is, what happens when your logic depends on something in a database?
Which kind of framework? What patterns would it implement? If you take a look at Martin Fowler's catalog of Enterprise Application Patterns [1], you'll see quite a few having to do with accessing data sources.
What I'm trying to say is that there is no "right way" to implement this, so I'm -0.5 against providing any kind of JDBC encapsulation code in flowscript, like it were some kind of "best practice".
I would have to agree with this. It's tempting to make the Flow "as easy as PHP" and just give everybody tons of functions to do stuff with. The problem is if we provide too much, then people will just start writing EVERYTHING in the Flow, and before you know it, it's out of hand.
I guess the same would go for the use case of wanting to fire off a simple email message from the Flow. But I guess if the user wants to do something that complicated, it would be trivial for them to just write a helper class in Java that they could access through Packages.*
Thoughts?
Tony
