|
I agree, it should probably be cut down to a small, flexible design with only a couple of the ideas we have put forward.
But what do you think are the best ideas, Marc? This is your project to lead.
Jason Henderson latest CPP news
"If you are going through hell, keep going." - Winston Churchill
|
|
|
|
|
Jason Henderson wrote:
it should probably be cut down to a small, flexible design with only a couple of the ideas we have put forward
We also have to remember that people are volunteering their own time, so it has to be fun, short, and engaging.
I don't know if this will be engaging to everyone, but the idea that's crystalizing for me, after reading all these posts, is a framework implemented in C# that provides for the near painless integration of scripts for the purpose of unit testing, regression testing, prototyping, and workflow specification/changes. The .NET framework really makes this possible with its Reflection, Type, and Activator namespaces/classes, allowing "remote control" of methods, properties, parameters, etc.
(Pardon the sounding board). I think this is doable, interesting, uses some fun technologies, and results in a really useful product.
Comments?
Marc
|
|
|
|
|
Sounds good!
It could be used as a built-in debugging/testing apparatus even after a production release.
Over the last couple of years, I've really been pushing for better error logging and application logging in our apps and it makes a world of difference. Adding scripting support would really help our QA team.
What about MACRO recording? Kind of like outputting to your script language for latter playback.
Jason Henderson latest CPP news
"If you are going through hell, keep going." - Winston Churchill
|
|
|
|
|
I've been toying with the idea of using C# or VB as the scripting language for macros/scripting, since the VB/C# compilers come with the .NET framework.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
Jason Henderson wrote:
Over the last couple of years, I've really been pushing for better error logging and application logging in our apps and it makes a world of difference. Adding scripting support would really help our QA team.
I was project lead many years ago on a project that was allocated 6 months of testing. The product was released after 3 months. Why? Because of instrumentation. Have you any idea how nice it was to look at event logs instead of asking QA "what did you do to make THAT happen?"???
Yes, you probably do!
Jason Henderson wrote:
What about MACRO recording?
Great idea!
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator. Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus Every line of code is a liability - Taka Muraoka Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
Marc Clifton wrote:
Have you any idea how nice it was to look at event logs instead of asking QA "what did you do to make THAT happen?"???
Yes, you probably do!
Oh yeah.
Marc Clifton wrote:
Great idea!
thanks
Jason Henderson latest CPP news
"If you are going through hell, keep going." - Winston Churchill
|
|
|
|
|
If anything, I must admire the timing. I'm currently in the midst of designing, or trying to find design notes or methodologies for developing scriptable applications, while also allowing record and playback via the GUI. Sounds like what's being discussed is pretty much on the mark (no pun intended). I will point out that I have contacted Microsoft to get their concepts on the matter, since they've obviously implemented this once or twice. We'll see where that goes.
I'd like to see how things progress, and would be happy to contribute (I just can't believe there's no serious development environment for C# other than VS.Net - which I can't afford personally). Several thoughts:
I agree with having the Scripting Layer be one of the foundations of the Application Framework. Having this embedded and not as a plugin, I believe, would allow for other plugins to expose information to the scripting layer, thus allowing them to be part of that interaction. Furthermore, it will allow for record/playback IF, and probably ONLY IF there's a good definition of GUI to Actions, and Scripting to Actions. What I mean by this is that the GUI should have, as per your AAL, pretty much NO code in it other than execution of actions, which would be mimicked by the script. Thus, record & playback of data manipulation would be straigtforward. Of course, you always get into that whole deal about scripting GUI (which is a mess - opening/closing windows, selection, active window, search & replace, bla bla bla) - I'm happy to assume I don't really need that peice.
... will 2 cents do? I'm dry out of blood...
Yaron Golan
Yet Another Developer
|
|
|
|
|
YaronGolan wrote:
I just can't believe there's no serious development environment for C# other than VS.Net - which I can't afford personally
Have you seen SharpDevelop?[^]?
YaronGolan wrote:
Having this embedded and not as a plugin, I believe, would allow for other plugins to expose information to the scripting layer, thus allowing them to be part of that interaction.
Not to sound repetitive from my reply in your previous message, but take a look at the prototype.[^]
YaronGolan wrote:
and probably ONLY IF there's a good definition of GUI to Actions, and Scripting to Actions.
This is an interesting point that I haven't considered. My focus for the vision of this thing is that it is a mediator that has user defined workflow processes triggered by events or state change.
YaronGolan wrote:
Of course, you always get into that whole deal about scripting GUI (which is a mess
Exactly. Even in the AAL, it's not that easy. I've been adding direct GUI control and the issues of window control--opening and closing in particular--is a pain because of the way the messaging system works in MFC. For example, when closing a dialog, I have to add a message to resume script processing, terminate the current script processor, and release control back to MFC. Very annoying and prone to errors.
If you haven't joined already (and you're still interested), sign up for the CPPSF mailing list and send everyone a brief Bio. Here's the project kick-off email:
http://www.codeproject.com/useritems/CPPSF_DIARY.asp#xx524776xx[^]
Thanks for you interest, Yaron. I really like your ideas and thinking!
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator. Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus Every line of code is a liability - Taka Muraoka Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
You know, I develop (too much, I think) code for server side components. The DAL is, IMHO, quite well (although not optimally) addressed by the .NET framework and several 3rd party tools out there.
The UI part is a well solved question these days, although a very time consuming part.
What still really requires lots of work is the BLL, and has small help from most frameworks, and all the components orchestration. There are deployment issues, too, that could be addressed by the idea I'll show you. I'll try to put it on words, but, without a diagram maybe it becomes hard to understand.
The BLL is composed of "components": I'm not caring yet about what's a physical implementation of a component, it could be a DLL, an EXE, a script (whether proprietary or not), a .NET class, or all of them.
Each component has a declared set of input and output data, and validation rules. Each component can be "plugged" (maybe visually, on an editor) on others depending whether the set of inputs and outputs are compatible or not.
Each connection has attributes that guide the execution flow, like the DTS designer for SQL Server, so components can be executed "on failure", "on commit", "on validation failed", "on ok", "queued", "in n-ways parallel" (reducing problems with multithreaded code). The components could be stored on repositories (obviously, suject to source code version control), and reused between several projects.
I think we could be really inovative creating something like this as an AF, just like event-driven code was several years ago, and some said "what? Do you mean I need to split my code in all those small event handling functions?". The same thing applies here: "what? Do you mean I need to split my business rules in all those data processing functions?"
The idea, here is the same behind Windows and event-driven UIs: you are not in control of the flow anymore, the system and the user are.
So, the AF would be this huge (actually, its code would be small) component orchestrator.
Kant wrote:
Actually she replied back to me "You shouldn't fix the bug. You should kill it"
|
|
|
|
|
Daniel Turini wrote:
What still really requires lots of work is the BLL
Exactly!
Daniel Turini wrote:
Each connection has attributes that guide the execution flow
Interesting idea.
Daniel Turini wrote:
So, the AF would be this huge (actually, its code would be small) component orchestrator.
Basically, that's where I think we're at. Nothing ships without an API nowadays, and usually the API is complex enough to be classified as a framework. What we need is an umbrella framework (I used that term in an earlier post somewhere too).
Stupid question, but it's because it's hard for me to shift mental gears--tell me how this is different from my AAL framework (yes, this is a major reference point for me, so it helps me to think in terms of that context. Whack me over the head if you get tired of hearing about it)? What areas are specialized?
A diagram would be great. Do you have the time to gen one up? I have Visio, or a JPG or GIF would be fine too.
And thanks for the post. I'm finding that there's more people than just little ol' me that is thinking along these lines. It's nice.
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator. Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus Every line of code is a liability - Taka Muraoka Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
Marc Clifton wrote:
Stupid question, but it's because it's hard for me to shift mental gears--tell me how this is different from my AAL framework (yes, this is a major reference point for me, so it helps me to think in terms of that context. Whack me over the head if you get tired of hearing about it)? What areas are specialized?
Whack!
Basically, if I understood and remember it right, your AAL is a kind of data-centric, and with a "data hub" raising events that start moving the gears. This, in my point of view, is great, but has a really big impact as how applications are designed.
My design is process-centric, and can imply in much less impact, with most of the gains of AAL. Data is "merely" an input or an output of a process. The most similar diagram that I can imagine is a multi-layer perceptron (maybe because I work a lot with neural networks, I tend to design several things like NN). A process is this huge collection of very small and simple components, like hidden layers of the perceptron. It has an "input layer", where you feed it with some data, and an "output layer", where you can collect the resulting data.
There are other things I didn't mention, like "data adapters", which are components that can get data output by a component and convert it to make it suitable to another component (e.g., a Celsius-Fahrenheit conversor).
Marc Clifton wrote:
A diagram would be great. Do you have the time to gen one up? I have Visio, or a JPG or GIF would be fine too.
I'll do one when I get home. You know, I'm supposed to be working, right now
Kant wrote:
Actually she replied back to me "You shouldn't fix the bug. You should kill it"
|
|
|
|
|
Daniel Turini wrote:
Basically, if I understood and remember it right, your AAL is a kind of data-centric, and with a "data hub" raising events that start moving the gears. This, in my point of view, is great, but has a really big impact as how applications are designed.
That's what I don't like, also. Helpful, but not what I'm looking for.
Daniel, I'm interested to see your ideas , and I am working on a model of mine, as time permits. I think that together we can do much better than we could singly.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
jdunlap wrote:
That's what I don't like, also. Helpful, but not what I'm looking for.
Ack. The forest for the trees problem. It's only because I haven't gotten to the workflow manager, the script engine, etc. Process management has a big role (at least equal to data management) in the AAL universe.
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator. Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus Every line of code is a liability - Taka Muraoka Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
Ah yes, I can see how this impression is arrived at. However, there's some big pieces that I haven't gotten to yet--the workflow manager/script engine, data access layer (yeah, I know!), etc. The plug-in architecture is essentially complete. However, you are correct also--it is more data-centric (the MFC version was really process centric, and it had some drawbacks). So I decided to tackle the problem from the other side.
However, to me, data is the key, because people get into so much trouble trying to manage it.
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator. Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus Every line of code is a liability - Taka Muraoka Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
Marc Clifton wrote:
However, to me, data is the key, because people get into so much trouble trying to manage it.
We'll want to be sure to address data management, but not only that.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
|
vote for participation in AAL development here.
|
|
|
|
|
Vote for doing something new here.
|
|
|
|
|
To me, the idea of an application framework consists of:
a way to manage services - a service being a component in the application that performs a service for other components in an application (for instance, a property or resource manager, a file IO manager, etc.)
a way to manage addins and the extensions they provide - an addin being an external assembly/assembly group that extends the intrinsic functionality of the application
some basic services, such as:
property manager service - stores global properties
there would also be a standard interface and base class to automate the reading and writing of properties
messaging service - a system for outputting messages to the reader.
Any component can add its own "messenger" to the messenger collection. The messenger takes care of outputting the message to the user. In this way, we can abstract the message from its method of output. The message center routes the messages to where they should go - for instance, it could route log messages to a log file messenger, hints/tips to an MS Agent character messenger, input messages to a messagebox messenger, status messages to a status bar our output window, etc.
resource service - manages global resources
a standard model for automating commands
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
Those sound like great ideas. I'm curious, since the AAL addresses a lot of these issues, how you would do things differently. Can you give me a mental picture of what you have in mind or, if you have the time, a physical picture, that helps to put some meat on the ideas?
Marc
|
|
|
|
|
Marc,
I think I know where he's going with this. Most of what he's described are the underpinnings of SharpDevelop. Most (not all) implement a set of interfaces that are used to stanardize basic functionality. They are implemented as Singleton objects and managed by a Service manager for accessability. The base architecture isn't too complex, but I'm not fond of some of their implementation. They were inconsistent about their prototyping and inheritance and in some cases it bytes them in the tail. It's a good architecture, and the ideas are sound, but I think we could improve/expand/re-implement them in a way where they are a bit more refined.
Mark
---------------
Mark Conger
Sonork:100.28396
|
|
|
|
|
Mark Conger wrote:
Most of what he's described are the underpinnings of SharpDevelop.
Correct.
Mark Conger wrote:
It's a good architecture, and the ideas are sound, but I think we could improve/expand/re-implement them in a way where they are a bit more refined.
Exactly.
I like the ideas in SharpDevelop, but there are a number of ways to improve upon its framework. And, of course, I have plenty of new ideas too. (For instance, my message center and my menu/toolbar framework - I did a complete re-design of both of them - the message center because it only had one output method, and the menu/toolbar system because it did not support customization. And of course, we want to give everyone a chance to add their own ideas.
What I especially like about SharpDevelop's architecture is the properties/addins/codons stuff. The rest I could throw out anytime.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
I agree with you, but even the plugin system needs some work. Have you ever tried to implement loading and unloading? think about it. that means plugins get loaded in different AppDomains and you have to implement communication accross domains, the possibility for the property service to need to manage the fact that properties appear or disappear becuse the owning plugin gets unloaded, yadah ,yadah. Their base system is nice no bout, but it still needs some rethink in some spots.
We also can't base anything on their code because they are actively selling that as a core product so using those concepts could get sticky.
Mark
Mark Conger
Sonork:100.28396
|
|
|
|
|
Yeah, I've been thinking it over, and I have thought of some ways to make their systems more dynamic. BTW, when I say "like SharpDevelop", I don't mean an exact clone. I mean the general idea, but greatly improved. Believe me, while working with their code, I got a good idea of the flaws in their system, and a desire to improve upon it.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
To make myself more clear, these are the areas I like:
An addin tree with extension points, and "codons"
The ability to persist a given class to XML, through a common interface.
A global property center, which holds/reads/writes the global properties
A collection of services to do various services that most parts of the app will use
Those are the ideas I like. They do not have to be just like SharpDevelop.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|