In order to add new threads or reply to existing posts, you have to be logged-in. If you are not registered yet, you need to register first, and then login with your personal credentials.
Is there a textual representation of the DSL? It looks to me like you must use the visual designer to create everything.
Todd,
it is indeed the purpose of CslaFactory to provide a visual designer to create your models. However, the DSL is serialized in XML, so to answer your question: yes, there is a textual representation of the DSL. You CAN edit the model with a texteditor, but that does not make any sense in my opinion. What exactly do you have in mind? Why do you want to omit the clarity, validation- and undo-capabilities provided by the visual designer?
Marcel
I guess I simply have different expectations for what a Domain Specific Language is. In my mind, a DSL is a human-readable (and writable) language (not XML). Validation of the DSL is achieved by a compiler/parser/interpreter. Visual tools could be created to generate the DSL or the DSL could be manipulated directly by hand. Tools like ANTLR (www.antlr.org) are great for creating DSLs that fit this definition. In my opinion, once you become very familiar with a framework such as CSLA, the visual tools can slow you down. If there is a friendly human-consumable DSL that drives the codegen, the visual tool can be considered syntactic sugar for the beginner. Intermediate and power-users can become more productive by manipulating the DSL directly.
Can you provide an example of how a human-readable DSL for CLSA.net would look like?
Here is a brief sample of what I was thinking...
// // Define roles for authorization // role Administrator, ROUser, User // // Define DB for persistence // database Analysts type relational tables Users, Roles end table Users int UserID pk,identity string FirstName string LastName string LoginID string PwdHash bool Active end table Roles int RoleID pk, identity string Name end table UserRoles int UserID fk,Users:UserID int RoleID fk,Groups:RoleID end // // Define Business Objects // switchable Role readonly property string Name end childlist Roles : Role dbmap Analysts:Roles // DB:Table, if no props specified, then table def implies properties end child User dbmap Analysts:Users children Roles end rootlist Users : User access read User, ROUser write Administrator end end Many more details would need to be defined, but I think this shows the basic idea.
Is far as I can see from your example, we do not have different expectations for what a DSL is. In fact, your example is very similar to the XML-representations of CslaFactory models. I noticed your example code NOT being XML and I understand that manually writing your kind of code is faster than writing XML. Nevertheless, it is similar to our DSL and I can easily imagine a tool importing such textual representations into CslaFactory. However, I am not very enthusiastic about your idea, because in reference to larger models, a text file does not provide the same clarity a model provides. The linear structure of a text-style DSL is easy to use in compiler rules, but not consequently easy to use in solution rules. And although a power-user might be very fast creating a textfile, the result tends to be full of syntax errors. We strongly believe that a graphical model is the "most natural" representational form of CSLA.net solutions.
I'm not against visual models. I simply don't want to be forced to always use them. Visual models don't typically scale well to fine levels of granularity. The system I'm currently working on has well over 500 business objects. Looking at 500 objects on a design surface is not practical. Of course I suppose I could support a large number of business objects by breaking this up into multiple solutions. However, over time as the system grows, the visual models are likely to become large regardless. I don't understand your point about linear structure of text-style DSL and how this adversely impacts solution rules. Could you clarify this?
Keeping up clarity while managing 500+ business objects is quite a task - no matter if you use models or text files. Perhaps this is one of the lessons learned using UML: A complex solution should not be visualized and maintained in one model. The current version of CslaFactory only supports independent models, but we are going to introduce ports. Our plan is to enable you to connect multiple models and reference business objects from different models.
The linear structure of a textual model helps the compiler to recognize the rules of the DSL, but it does not necessarily help the user to understand the rules of the solution.