|
I agree. Scripting within a plugin framework is the way forward. At least I think it is. Currently I only use limited VB scripting at the moment but am hoping to move forward and work on a C# based system.
On the fly system changes. So when I'm on site and the customer says, "Can we make it so the user has to enter this first and then that rather than the way we originally asked for it." I can make the changes without a problem, without having to recompile and still making it straight forward to go back to the original when they change their mind back again. (Oh and still charge them twice  )
My dream.
Michael
'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
|
|
|
|
|
You're aware systems like Smaltalk have had this for ages (Smalltalk goes back to 72-73)?
But they have never caught on. (AFAIK)
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
|
|
|
|
|
Jim Crafton wrote:
You're aware systems like Smaltalk have had this for ages
Oh yes. Scriptable, pluggable applications have been a dream of mine since I started coding. Sadly I've never come across a decent enough platform that allowed for the kind of flexibility that I require.
C#, .NET and XML are the new best hope for implementing my vision. I wish I had the time to start building it, but at the moment paying the bills is taking precedence. Plus I have the vain hope that Microsoft will change .NET to support XML based forms rather than the code based WinForms. One of the keystones of my ideas requires that the user-interface be altered on the fly, something that C# doesn't really support as native. And I hate to write something that might turn up in the next .NET release.
Michael
'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
|
|
|
|
|
Michael P Butler wrote:
One of the keystones of my ideas requires that the user-interface be altered on the fly, something that C# doesn't really support as native.
I really should do that in my next AAL article.
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
Michael P Butler wrote:
One of the keystones of my ideas requires that the user-interface be altered on the fly, something that C# doesn't really support as native
Yeah, .NET really neads an XForms implementation for WinForms. Somthing like this[^]. But less crap.
Ryan.
|
|
|
|
|
Michael P Butler wrote:
Sadly I've never come across a decent enough platform that allowed for the kind of flexibility that I require.
The VBScript run-time for instance allows just this, and it's available for a bunch of years.
Another example, my former company pays Microsoft 150,000$ dollars a year to host the VBA editor into the product line, and as a result make the application scriptable and debuggable interactively.
Michael P Butler wrote:
C#, .NET and XML are the new best hope for implementing my vision
Don't forget that Xml is only going to bring the lowest common denominator in terms of UI. If you are looking for fancy UIs, it's clear to me that you need custom code, not xml.
I have been repurposing ActiveX properties and methods using xml, and build UIs on top of this and it's my own experiment that the UI is too simple. For instance, I need to add a validation layer to the UI, and the beauty of xml declaration (as seen in articles) is not going to help a lot in this area. My 0.5 cent.
RSS feed
|
|
|
|
|
Stephane Rodriguez. wrote:
The VBScript run-time for instance allows just this, and it's available for a bunch of years.
I have VB script plugged into a number of my applications. It does the job, but it's not really what I'm looking for for the flexibility.
Stephane Rodriguez. wrote:
Don't forget that Xml is only going to bring the lowest common denominator in terms of UI. If you are looking for fancy UIs, it's clear to me that you need custom code, not xml.
I have been repurposing ActiveX properties and methods using xml, and build UIs on top of this and it's my own experiment that the UI is too simple. For instance, I need to add a validation layer to the UI, and the beauty of xml declaration (as seen in articles) is not going to help a lot in this area. My 0.5 cent.
What I want to try and achieve to start with is the equivalant of the .RC file. Except my application will parse the resource file at run-time rather than at compile time. I will be only limited by the controls that my forms runtime knows about, which is where the plugable architecture comes in.
It should be possible to devise an XML schema that allows validation to be described so that the forms runtime can validate the forms without having to code it for every form.
I don't know how much of what I plan to do is achievable or technically possible. I need to spec out my feature set first, then see if I can design and implement it.
Michael
'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
|
|
|
|
|
Michael P Butler wrote:
What I want to try and achieve to start with is the equivalant of the .RC file.
With C/C++ code you can already decide to go the hardcore way and creating controls yourself instead of using .RC dialog templates. Using Xml to describe controls is like cheese, and you there are implementations for this already.
The point is that, once you get down to UIs you start needing things like "conditional properties", that is things that react depending on some selected values, or things that popup depending on user actions. And Xml does not bring you the plumbing. The plumbing is still plain row code.
While we are at it, what I like about dynamic UIs is more the achievement of separation as most as possible of the application logic and the UI logic, using a subscription model (windows messages) which notifies of events, rather than writing new APIs over and over again, which ends up like specialized and costly code to maintain.
My 0.5 cent.
RSS feed
|
|
|
|
|
Stephane Rodriguez. wrote:
The point is that, once you get down to UIs you start needing things like "conditional properties", that is things that react depending on some selected values, or things that popup depending on user actions.
That's one of the things I'm researching. In theory most of these actions could be described as business rules. As they are rules, they should be able to be described in meta data. For anything that the metadata file cannot handle, well that's why I need scripting.
Stephane Rodriguez. wrote:
While we are at it, what I like about dynamic UIs is more the achievement of separation as most as possible of the application logic and the UI logic, using a subscription model (windows messages) which notifies of events,
Me too. That is my aim, to seperate the UI logic from the business logic. I know that a lot of what I want is a pipedream because at the end of the day we'll always need some code writing. I'm just trying to find a way to avoid having to write the boring form/form validation/data loading and saving without having to resort to code generators.
Michael
'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
|
|
|
|
|
|
|
|
Uwe Keim wrote:
...and so... what did Google say?
At a guess.
Been There, Done That.
Michael
'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
|
|
|
|
|
|
If you downloaded cygwin, you have that cool little utility, wtf.exe:
dturini@desnn ~
$ wtf BTDT
BTDT: been there, done that
You can do it on anything you choose - from .bat to .net - A customer
|
|
|
|
|
Scripting?
That is because Scripting Framework project?
Or Scripting Framework project because scripting?
I am very like IDispatch and IMoniker but not sure that
future it is scripting. May be, but when I think about
Borland C++ Builder, Delphi, Visual Basic, C# and even
UML I think that future it is visualization in
programming and languages. The man must see (in mind) what
he create as Plato said  . The world of things, the
world of ideas...
|
|
|
|
|
My current experiences with scripting languages use another kind of *poof*.
"Dor säggsische Dialeggt eechnet sich wie keeen onderor für den Ausdrugg zäärdlischor Gefiehle."
sighist | Agile Programming | doxygen
|
|
|
|
|
|
Perl is still very good for advanced text parsing.
I know no language where You can write a C++ parser faster which
does e.g automatically insert trace statements at top of each
function with class/function name replacement in the trace text.
Alois Kraus
|
|
|
|
|
|
Sure you can do it in other languages. But the fastest way ist still
perl. The regular expressions are part of the language which
leads to the most compact syntax. And it is free and portable without
any fees.
|
|
|
|
|
Java is losing ground fast, and it never 'stole the punchline' from PERL.
Use of PERL is not all that common in the Windows world, but if you use any *Nix system, PERL is a savior!
For example, try writing a program to parse a UNIX log that tracks logins for an entire network in C#, C++, or Java and you will quickly find yourself focusing more in memory issues and locations of certain characters (and the # of lines of code for the program will be close to a hundred just to get it to run as a daemon). Write a script in PERL and it does all of that for you in about 10 lines of code.
"If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week"
|
|
|
|
|
Zac Howland wrote:
Use of PERL is not all that common in the Windows world, but if you use any *Nix system, PERL is a savior!
I beg to differ! We use Perl all the time in Windows environments. We have a build environment, much of it automated. Most, if not all, of that is Perl scripts.
I would venture to say that most sizeable operations that have the concept of a build (e.g., not just people compiling on their own machines, then cobbling together a web package or CD from that) will probably be making use of Perl.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
I was not trying to say that it is never used in Windows development. I use it to do many different tasks. What I was getting at was that it is used much more in *Nix environments.
"If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
