 |
|
|
jdunlap wrote:
provide a standard command interface so that commands can be invoked from menus, toolbars, directly from code, etc.
jdunlap wrote:
Extend the application
I like these ideas.
Jason Henderson My articles
"The best argument against democracy is a five-minute conversation with the average voter." - Winston Churchill
|
|
|
|
|
i want to add you on skype
could you please give me yours skype id
|
|
|
|
|
Hey Marc! Grats on being the boss 
(Did I miss Part 1 somewhere?? Me no see it :P)
AF, abstract? Nahhhh.
As I see it there is one big pitfall with an AF. IT's trying to make it do too much. I've been playing with AF ideas for over 2 years now and I've fallen into this trap too many times. The tendency is to make it do everything and the kitchen sink. What you need t remember is start with a core base set of services/functionality and let the framework evolve. Remember, the key word is abstract!
The other thing to keep in mind is that a AF does not necessarily mean plugin architecture. An AF simply is there to provide base services to something. If we want to include extensibility plugins, so be it, but let's not make their names synonymous (although I think plugins may be a foregone conclusion :P)
The last couple months, I've scrapped what I was working on and tried to come at the whole thing from the concept above. I asked myself what base services do every application I write need to have or that I am constantly asked for? What has to be down at the "Ring 0 and 1" of my application at the start and can't be bolted/added on later?
I usually come back to 4 things:
1) An ability to manage properties for the application.
2) The ability to manage resources (usually include globalization/localization in here)
3) A internal relatively simple, eas for the layman to use scripting engine of some sort allowing the user to be able to write small macros or whatever to be able to extend the application themselves without resorting to having me change them 75-150 and hour to write something that reformats someone's info or some such.
4) A distancing of the GUI elements from Data elements and those from code constructs. (Marc's idea of a DataHub, GUI manager, etc basically)
Those are my usual focuses at the start. However 1,2, and 4 are probably the most realistic. Number 3 is in there because the more I have worked with the ideas the farther I've had to push that down into the lower levels of the app design. I believe the first two are a mandatory for any framework the other two are pure architecture discussions waiting to happen.
Marc, it may be a good idea to take a survey of the team and gather a little info like what peoples strengths are, what they would be using the AF for, etc. Those questions tend to point me to where my focus wants to be on a project. Also, I hate to bring this up, but what's an AF without a sample Application? I'm not saying we rewrite SharpDevelop or something, but it will be good to have a app built on our framework to test and showoff. (I know what I want to use it for, but it is SOOOO out of scpe its not funny :P)
Just some ideas.
Mark
Mark Conger
Sonork:100.28396
|
|
|
|
|
It's amazing what a hour drive, 20 minutes of roadrage, ad a government screwup will do to clear your head.
Ok, let me step back and clarify some stuff.
the services that I mentioned and that have been kicked out are all valid points, but they are a little narrow for describing a framework. what I was originally envisioning was something like
----------------------------------
Presntation Manager
----------------------------------
| Script engine | |Data Manager|
----------------------------------
Services Subsystem
----------------------------------
Presentation manager is a GUI manager front end. It handles the controls and allows for interconnect between the lower subsystems and the front end presentation objects.
Script engine is pretty obvious.
Data hub is much the same as Marc's data hub concept (abstract the system from the data)
Services Subsystem includes stuff like a service to manage properties, resources, plugins (if it has that kind of system), etc.
Just tossing stuff out. Tear it to shreds
Mark Conger
Sonork:100.28396
|
|
|
|
|
Mark Conger wrote:
----------------------------------
Presentation Manager
----------------------------------
| Script engine | |Data Manager|
----------------------------------
Services Subsystem
----------------------------------
Looks good.
"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
|
|
|
|
|
Mark Conger wrote:
Services Subsystem includes stuff like a service to manage properties, resources, plugins (if it has that kind of system), etc.
In the MFC version of the AAL, and as you will see in the next installment of the C# version, the presentation manager IS a plug-in. Also in my MFC version, there is a custom script engine, itself another plug-in, allowing you to change scripting engines if you don't like mine.
So I personally disagree with constructing a framework that ultimately may support plug-ins but does not implement plug-ins for its own components. Therefore, a plug-in architecture must be developed first.
Conversely, if you "just" want to develop a presentation manager AF, or a script engine AF, or a property manager AF, that's fine. These things are simpler, being self-contained.
Keep in mind though that you end up with a lot of diverse AF's, requiring a meta-AF to integrate them all. And that's sort of what we have already with MFC and .NET. However, it is a smaller bite to chew, and if people want to do that, I'd be happy to go along for the ride. It just doesn't suite my needs, though.
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"
|
|
|
|
|
Hey Marc
I think you've misunderstood me....
I've not looked at your MFC version and I'm trying not to look at other Frameworks to prejudice myself and want to rob ideas all the time Also, as for your C# AAL, that's great. In my concet I didn't have a plugin system. I was considering one when talk of this project was getting started so I tabled it. I'm sure it was possible for the script engine to be a plugin, but I'm not sure I would do that. It would make it much more difficult for plugins to register themselves as usuable objects with the engine for a couple of reasons I can think of. First off every plugin and GUI object would have to attempt to register itself with every other plugin because it could be a script engine. That would make the init/startup process slow and a nightmare.
Marc Clifton wrote:
So I personally disagree with constructing a framework that ultimately may support plug-ins but does not implement plug-ins for its own components. Therefore, a plug-in architecture must be developed first.
No worries. I can go either way with this one. As I said I was just investing some effort in redesign to include a better plugin system in the architecture when this got started. I've seen two schools of thought for this. One that has everything being a plugin, and one where most of the system is plugin oriented with a few core services that are always there and hence aren't pluigns themselves because they need to be instantiated before plugin load.
I wasn't trying to describe this as a GUI management system either, I was just floating the concept that the presntation layer shouldn't be left out. Take sharpDevelop. It has a fairly decent plugin system at the guts, but that plugin system doesn't carry itself very well up to the GUI elements very well. The GUI elements are managed by the indvidual plugins and dont interact much (or very well) with each other. It ends up with the interface being somewhat clumsy. What good is an application with this great pugin system if the intrface that the user is going to see every day sucks and ticks them off?
Marc Clifton wrote:
Keep in mind though that you end up with a lot of diverse AF's, requiring a meta-AF to integrate them all. And that's sort of what we have already with MFC and .NET.
I agree. I'm just floating ideas here since mine were coinciding with jdunlaps w and with a few others that chimed in. I think we are having a problem with the term "application framework". We've said "let's build an Application Framework!" but no one has defined what that term application framework means when it was voted on. We've had some people ask what the term means, some suggest an n-tier application architecture (arguably a framework, but not in the sense we were thinking), a p2p architecture.
I suggest that first order of business should be that we define this term for us. It will help us set what our requirements are at a 100000 foot level. It will also get all of us on the same page for expectations and be able to give better ideas for what we want to do instead of going off in tangents.
Mark Conger
Sonork:100.28396
|
|
|
|
|
Mark Conger wrote:
First off every plugin and GUI object would have to attempt to register itself with every other plugin because it could be a script engine.
Hmmm. I'm not sure I follow you on this one. I've always had plug-ins register their published interfaces with a common dispatcher.
Mark Conger wrote:
and one where most of the system is plugin oriented with a few core services that are always there
True--at a minimum, you need something to be able to load plug-ins! 
In any case, while a plug-in application framework is interesting, there are complexities that are probably beyond the scope of an initial CP2 project.
My ears perked up when you mentioned a script engine. I'm definitely leaning toward this right now--a script engine application framework (OK, really a fancy name for a set of classes that let you add scripting capability to your code). What do you think?
Mark Conger wrote:
I suggest that first order of business should be that we define this term for us.
Well, my opening message on this thread provided two definitions. How do those sound?
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"
|
|
|
|
|
Well, I'll look forward to your article involving GUI objects, because the problem I typically run into is the plugin system is completely unaware (and should be) of the GUI itself and therefore tends to be tough to make the two force interaction.
I agree, the complexities are huge for something like this. Better to observe KISS
A scripting engine at the core seems to be the missing item for most .NET frameworks. I have yet to see a .NET framework that implements one that's worth a damn. I stuck this in because I typically get asked for stupid stuff on interfaces like changing a font for a whole document or automating some process that I end up having to write a module for instead of a quick macro.
either one is acceptable, we just need to stick a stake in a vampire...err ground.
mark
Mark Conger
Sonork:100.28396
|
|
|
|
|
|
Submit an article or tip
Post your Blog
![Rose | [Rose]](/script/Forums/Images/rose.gif)
Extend the application
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin