|
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
|
|
|
|
|
I know what ya mean, but we have to tread lightl on those concepts if we use them since they are a licensed, selling product
Mark
Mark Conger
Sonork:100.28396
|
|
|
|
|
There are enough ways that we could/would/should make different that we shouldn't have a problem.
"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
|
|
|
|
|
Marc Clifton wrote:
OK, what's your idea of what an application framework is/does?
I'm still not sure I understand exactly what an app framework is. Is it like Document/View in MFC or is it deeper, like MFC itself, or deeper yet? Is it like .NET, or maybe DirectX?
Can it be built on top of another app framework?
If it is what I think it is, here are some ideas:
1) XML defined UI or a basic method of user customization through XML or scripting.
2) encapsulation of multi-threading that makes it 100x easier to use.
3) easier coupling/decoupling of components (a better COM interface)
4) built-in application logging
5) built-in easy app preferences saved to XML
6) ODBC/ADO built-in
7) easy window creation (a window data type)
8) HTML parsing/rendering/functionality on windows
I could go on, but I really don't know if my definition of app framework is correct.
Jason Henderson My articles
"The best argument against democracy is a five-minute conversation with the average voter." - Winston Churchill
|
|
|
|
|
|
I'm glad I wasn't completely out of my mind then.
A cool feature to me would be user customization through scripting or XML. I'd like to be able to define a UI through XML too. Imagine changing the UI without re-compiling! I think netscape was doing something like this.
Jason Henderson My articles
"The best argument against democracy is a five-minute conversation with the average voter." - Winston Churchill
|
|
|
|
|
Off the subject, but I don't know where to ask it:
Should we vote down the option we don't like, or just vote up the one we like? Maybe the latter is better, as the former gets a bit confusing.
I've wondered about this a number of times - where do we ask questions like the above question? Can a forum be set up for asking CP2 questions?
[BTW, I'll gladly delete this if you want.]
"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:
Should we vote down the option we don't like, or just vote up the one we like?
I've used both. If I don't like an idea that is getting a lot of votes, I vote it down.
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"
|
|
|
|
|
This is Marc's message board so you don't have to delete it unless he wants you to. I just want to keep the main CPP message area clean.
I always vote down and up since if you don't like something and don't vote then everything would be 5's, but if you vote for both (down and up) then things even out more.
jdunlap wrote:
where do we ask questions like the above question?
Ask it in my personal message board on my who's who page here on CP.
Jason Henderson My articles
"The best argument against democracy is a five-minute conversation with the average voter." - Winston Churchill
|
|
|
|
|
Jason Henderson wrote:
I'd like to be able to define a UI through XML too. Imagine changing the UI without re-compiling!
You'll enjoy the next installment of the AAL then. XML defined GUI's, runtime dynamic GUI generation. he he he.
Marc
|
|
|
|
|
hehe, XML control of the GUI seems to be where everyone is headed.
(SharpDevelop's XMLForms, your next installment of AAL, couple other projects on Sourceforge)
Mark
Mark Conger
Sonork:100.28396
|
|
|
|
|
Jason Henderson wrote:
Is it like Document/View in MFC or is it deeper, like MFC itself, or deeper yet? Is it like .NET, or maybe DirectX?
From what I read doing a quick google search, these are all examples of an application framework. The MFC/.NET frameworks have considerable breadth, as it embraces just about every tier of an application--presentation, data access, business, instrumentation/profiling, component management, activation, memory management, data management, etc. From my point of view, the breadth has sacrificed a lot in depth. By depth, I am referring to that vague concept that makes it easier for the programmer to tie together whatever pieces the specific application requires. In the AAL, I've taken the position that 99% of programmers either don't know how to do this integration, aren't aware that it's necessary, or don't have the time. In all cases, my approach is that the framework needs to facilitate this integration in spite of the programmer's relative skills. This becomes particularly important in projects where there are several developers of varying skill.
Jason Henderson wrote:
I could go on, but I really don't know if my definition of app framework is correct.
I think it is 100% correct. The playing field is so large at this point though, that like many engineering and science disciplines, specialization is probably required. The drawback to this is that you push the integration issues up. Instead of integrating between components, now you're integrating between disparate AF's. This may not be a problem for solutions that don't cross concerns (an AOP term), but most of the applications nowadays do. Hence (and I'm not arguing for the AAL, I'm using this as a sounding board to explain my rationale) the AAL builds on the existing AF provided by Microsoft (either .NET or MFC), and attempts to unify the two thing that they all have in common--data and command. The third and fourth parts of the AAL address the application's concerns--workflow and component integration. Hopefully what I end up with is an umbrella framework (hey, I coined a term!) that works with any underlying framework. For example, the Magic library that Carlos uses in his articles would be relegated as an additional assembly with appropriate wrappers to the AAL to ensure that data and command processes stay unified.
However, there are excellent reasons to work on an AF, perhaps better termed a "technology framework" that focuses on a specific solution for a specific technology. Personally, I think it should build on the framework that Microsoft already supplies. Better buy-in, can take advantage of new features as Microsoft develops them, and can leverage a ton of work already done, even if that's sometimes painful.
Hope you don't mind the lengthy explanation!
Marc
|
|
|
|
|
I read through your first AAL article last night. Its an interesting concept. I may want to play some role in this project.
Jason Henderson latest CPP news
"If you are going through hell, keep going." - Winston Churchill
|
|
|
|
|
Jason Henderson wrote:
I may want to play some role in this project.
Well, I guess I'd suggest reading the other 3 articles and letting me know what you have in mind.
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:
Well, I guess I'd suggest reading the other 3 articles and letting me know what you have in mind.
What I had in mind was joining the team and helping out in some fashion. I'm sure I could do something. I promise I wouldn't tell you what to do. I can be CPP Coordinator and a team member too.
I'm an ideas person, so if all I contribute are lightbulbs going off in your head then I'm satisfied.
Jason Henderson latest CPP news
"If you are going through hell, keep going." - Winston Churchill
|
|
|
|
|
|
|
Ways to do both:
1) MC++ can be used to wrap access to the .NET dlls for use by non-.NET languages.
2) Write it in C++, then use MC++ to wrap it for access to .NET languages.
3) Write it twice, keeping .NET and non-.NET languages completely separate.
Maybe none of them is a good idea, but I would lean toward #1.
John
"We want to be alone when we hear too many words and we feel alone when it has been a while since anyone has spoken to us." Paul David Tripp -- War of Words
|
|
|
|
|