+972 52-548-6969
Is this valuable?
time to read 1 min | 81 words
Going back to the theme of visually editing a DSL, we have something like this:
The backend to this cutey is pattern recognition with custom UI on top. You have to teach it about each pattern that you use with it, but you can get pretty smart with how it works while using a fairly brute force (and simple) techniques.
Thoughts?
Comments
Reverse?
Pretty cool. I imagine at some point there are too many levels of indirection between UI writing script, etc. and it's easier to just implement in straight C#.
The value to me for the DSL stuff is being able to use it as the requirements/documentation for what the software is doing in a readable format. Here the UI provides that, so the DSL doesn't add much value for me on this example at least.
Think of the way the WinForm docking works...
I agree that this is not really valuable in this scenario, but there are cases where having a visuaiation makes things much more simple.
Are you analysing the AST and building a UI from it? Or how does it work under the hood? I guess this is will be explained in the book :)
It looks very interesting.
I say it all depend on how well the parser work. Does it tie into the AST? I like where we are going but I am a little wary with current impl at the moment. If not then we got one more thing that can break... more testing involve. Maybe it's just me but a text base rule look pretty solid to me.
Torkel,
Yes.
Basically, I recognize the pattern of checking a user by role, and provided a UI for that
firefly,
The Parser is actually use the BooParser, which generate the AST, yes.
I don't like that this is mostly a "read only" GUI. It allows editing parameters of existing rules (Admin -> Administrators) but not adding new rules (User IsInRole "Customers" and CurrentTime IsInBusinessHours).
You could try to make it editable, but adding more complex rules would probably be more efficient using a text editor with good contextual autocompletion (intellisense) and integrated validation (underline errors and show error details on mouse over).
A GUI is more efficient when you can use the same layout for different operations on the same data. It's easier for users to "context switch" back and forth between reading and editing if it all happens in the same location. If the layout changes between reading and editing, users have to reparse the new layout every time, which consumes brain cycles and tends to remove information from their short term memory (they forget exactly what they were trying to do and have to pause to rethink about it). This may not look too much if all you do is edit one rule and then are done with it, but it gets extremely annoying when you have to work with tools that try to do everything graphically severals hours a day.
I like that you build this on top of a DSL instead of directly doing a graphical representation like most current tools. However, I see the text DSL as an evolution from graphical tools. Therefore, trying to represent them graphically seems like a step back, unless you find a revolutionary way to do a graphical representation of code.
It's sort of valuable, but not really from a usability point of view as I imagine you will end up with many rules.
First thing the user will need is good overview of all rules, filtered any way he want to, certainly by rule and role. Once he has that he will want to edit them directly in that view, in order to understand what he is doing.
Comment preview