|
|
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)
<sarcasm>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
|
|
|
|
|
Mark Conger wrote:
we just need to stick a stake in a vampire
BTW, did I mention the pint of blood donation for every person working on my project???
I've selected a scripting engine as the project. A plug-in manager is just too messy--too many ideas, issues with buy-in, need to support existing plug-in architectures like COM/ActiveX, etc.
Personally, I need a scripting engine, don't really like the one I wrote for the MFC version of the AAL, some nifty things can be done using .NET's reflection and type stuff (not to mention generating actual C# code for permanent scripts!!!), and I also agree with your reasoning--it is a powerful and useful thing missing from both the .NET and MFC frameworks.
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"
|
|
|
|
|
i use the jscript.net engine in my grid , it works very good , and its fast to.
checkout the microsoft.jscript.vsa namespace.
you can use this via c# to "Eval()" an expression..
e:
c#---
string MyStringExpression="10+20*4-5"; //string containing jscript expression
object o=MyEngine.Eval(MyStringExpression);
-----
if you are interesed i can send you a little sample later today..
//Roger
|
|
|
|
|
I'd like a visual workflow designer technology framework. It would provide a mechanism for specifying and managing application workflow issues, something that I haven't seen addressed at all, integrating an existing drawing package, like Visio, with VS's IDE. For example, the programmer should be able to specify the workflow in a point-of-sale system (an example only!)
It would be nifty to integrate the workflow with an existing drawing package like Visio, using flowcharting objects, etc. (I've done a lot of Visio integration in the past). The framework would provide the programmer the ability to:
1. prototype a workflow through an interpreter provided by the framework, reading the information off the diagram(s);
2. translate the diagram to C#/C++ code for the release version (or a compacted data file--XML?--What's with the XML bandwaggon, anyways???);
3. tight integration with Visio--double click on a graphic object and drill down to additional workflow specification and/or switch over to the "code-behind";
4. and the holy grail--reverse engineer a workflow when the programmer makes changes to the program! (OK, probably totally out of scope).
Comments? All in favor? All opposed?
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"
|
|
|
|
|
hehe. Sounds like Webmethods to me
It's not a bad idea
Mark Conger
Sonork:100.28396
|
|
|
|
|
|
Interesting, but:
How does this fit with an app framework?
What if people can't afford Visio?
"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
|
|
|
|
|
What Marc is describing is a application framework targeted at a true business solution. It's just a very narrow scope. In reality I have one application like thi now that I deperately need to rewrite because the idiots who did wrote 18 separate VB6 apps with little or no documentation or consistency.
Mark
Mark Conger
Sonork:100.28396
|
|
|
|
|
Sorry, I want to get some samples C# and .NET
About C#
|
|
|
|
|
do you have seen Microsoft's biztalk orchestation?
Federico
|
|
|
|
|
Sorry, Mark, my comment has nothing to do with the current discussion.
Just wondering if you deleted some of your articles. I was considering deleting some of my articles (those I am not proud of  ) from Code Project, but decided not to.
Click here to see my articles and software tools
|
|
|
|
|
I removed the 4 CPP Script Framework articles, as the project moved off of CP. I'll be posting articles about the development effort as real articles instead of "project articles".
And yeah, there's a few articles I'm not very proud of either. But I might consider deleting them when my article count is around 100.
Marc
STL, a liability factory - Anonymously
A doable project is one that is small enough to be done quickly and big enough to be interesting - Ken Orr
Latest AAL Article
My blog
|
|
|
|
|
I always loved to have a tight integration between visio and visual studio. I noticed that there was a link between the UML features of visio and visual studio.
That can be used to create the classes. The flowcharts can than be used to add the code in the function. However I think this kind of things can also be done with UML
Greetings....
|
|
|
|
|
Sorry if I am asking the wrong question.
What kinda of methodologies you guys plan to use? Ex: Agile methodologies like Extreme Programming, Feature Driven Development etc...
Never take a problem to your boss unless you have a solution.
This signature was created by "Code Project Quoter".
|
|
|
|
|
Kant wrote:
What kinda of methodologies you guys plan to use?
An interesting question. What drives it?
Personally, I tend to follow Feature Driven Development and Aspect Oriented Software Design methodologies. This is heavily influenced by the type of clients I have (and respectively, THEIR clients). From the Extreme Programming perspective, I like the ideas of unit and process testing (especially the build the test before writing the code), but I find that in practice they lead to a lot of wasted effort. Especially pair programming. Which is also impossible in this project for obvious reasons, unless we used something like GoToMyPC.com. Hmmmm.
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"
|
|
|
|
|
Could somebody explain what the AAL is? Is it just the name of this specific Application Framework project being discussed.
I'd like to see some built-in Unit Testing functionality in the new framework. I have written a few generic classes for testing and I now find them indispensible. Another thing that might be useful is some built in scripting. I think somebody may have already mentioned this, but the scripting could be related to the Testing so we could test the End-Product dynamically.
We'll also have to write a few VC Application wizards to create a skeleton app for using the library/framework. Another thing we should look out for is to make the framework as CrossPlatform as possible, especially since even MS themselves are taking an interest in Linux these days.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Extend the application