A rule in xText called "Component" will typically generate a class "Component" in the src-gen folder.
I would like to add additional methods to these classes without them being overridden every time I make minor changes to the DSL. What's the proper way to inject my own code into these classes and is there a way to make all classes extend my own root class instead of the default EObject?
Thanks in advance.
You basically have two choices:
You can use a IXtext2EcorePostProcessor to modify the EMF-model which Xtext inferred from your grammar. The actual code generation is done by EMF, so you have to fiddle your code through that bottleneck. The details are described in a blog of Christian Dietrich. This approach is only suitable for small modifications.
You can use the "generation gap pattern" (a.k. "implementation gap pattern") which allows you the write classes which derive from the generated model classes. Here you can add anything you want. The details are described in a blog of Heiko Behrens. This approach is better suited for large scale modifcations by inheritance.
You may of course mix the two approaches...
Related
I'm making a method inside a Ruby on Rails app called "print" that can take any string and converts it into a png. I've been told it's not good to make class methods for base ruby classes like String or Array or Hash, etc. so "some string to print".print is probably not something I should do.
I was thinking about making a subclass of String called Print (class Print < String) and storing it in my lib/assets folder. So it would look like: Print.new("some string to print"). So my question is, am I on the right track by 1) creating a sub-class from String and 2) storing it in lib/assets?
Any guidance would be greatly appreciated!
Answers to your question will necessarily be subjective because there are always be many answers to "where should I put functionality?", according to preference, principle, habit, customs, etc. I'll list a few and describe them, maybe add some of my personal opinions, but you'll ultimately have to choose and accept the consequences.
Note: I'll commonly refer to the common degenerate case of "losing namespacing scope" or "as bad as having global methods".
Monkeypatch/Extend String
Convenient and very "OO-message-passing" style at the cost of globally affecting all String in your application. That cost can be large because doing so breaks an implicit boundary between Ruby core and your application and it also scatters a component of "your application" in an external place. The functionality will have global scope and at worst will unintentionally interact with other things it shouldn't.
Worthy mention: Ruby has a Refinements feature that allows you to do do "scoped monkeypatching".
Worthy mention 2: Ruby also lets you includes modules into existing classes, like String.class_eval { include MyCustomization } which is slightly better because it's easier to tell a customization has been made and where it was introduced: "foo".method(:custom_method).owner will reveal it. Normal Monkeypatching will make it as if the method was defined on String itself.
Utils Module
Commonly done in all programming languages, a Util module is simply a single namespace where class methods/static methods are dumped. This is always an option to avoid the global pollution, but if Util ends up getting used everywhere anyways and it gets filled to the brim with unrelated methods, then the value of namespacing is lost. Having a method in a Util module tends to signify not enough thought was put into organizing code, since without maintenance, at it's worst, it's not much better than having global methods.
Private Method
Suppose you only need it in one class -- then it's easy to just put it into one private method. What if you need it in many classes? Should you make it a private method in a base class? If the functionality is inherent to the class, something associated with the class's identity, then Yes. Used correctly, the fact that this message exists is made invisible to components outside of that class.
However, this has the same downfall as the Rails Helper module when used incorrectly. If the next added feature requires that functionality, you'll be tempted to add the new feature to the class in order to have access to it. In this way the class's scope grows over time, eventually becoming near-global in your application.
Helper Module
Many Rails devs would suggest to put almost all of these utility methods inside rails Helper modules. Helper modules are kind of in between Utils Module and Private Method options. Helpers are included and have access to private members like Private Methods, and they suggest independence like Utils Modules (but do not guarantee it). Because of these properties, they tend to end up appearing everywhere, losing namespacing, and they end up accessing each other's private members, losing independence. This means it's more powerful, but can easily become much worse than either free-standing class/static methods or private methods.
Create a Class
If all the cases above degenerate into a "global scope", what if we forcibly create a new, smaller scope by way of a new class? The new class's purpose will be only to take data in and transform it on request on the way out. This is the common wisdom of "creating many, small classes", as small classes will have smaller scopes and will be easier to handle.
Unfortunately, taking this strategy too far will result in having too many tiny components, each of which do almost nothing useful by themselves. You avoid the ball of mud, but you end up with a chunky soup where every tiny thing is connected to every other tiny thing. It's just as complicated as having global methods all interconnected with each other, and you're not much better off.
Meta-Option: Refactor
Given the options above all have the same degenerate case, you may think there's no hope and everything will always eventually become horribly global -- Not True! It's important to understand they all degenerate in different ways.
Perhaps functionality 1, 2, 3, 4... 20 as Util methods are a complete mess, but they work cohesively as functionality A.1 ~ A.20 within the single class A. Perhaps class B is a complete mess and works better broken apart into one Util method and two private methods in class C.
Your lofty goal as an engineer will be to organize your application in a configuration that avoids all these degenerate cases for every bit of functionality in the system, making the system as a whole only as complex as necessary.
My advice
I don't have full context of your domain, and you probably won't be able to communicate that easily in a SO question anyways, so I can't be certain what'll work best for you.
However, I'll point out that it's generally easier to combine things than it is to break them apart. I generally advise starting with class/static methods. Put it in Util and move it to a better namespace later (Printer?). Perhaps in the future you'll discover many of these individual methods frequently operate on the same inputs, passing the same data back and forth between them -- this may be a good candidate for a class. This is often easier than starting off with a class or inheriting other class and trying to break functionality apart, later.
Is it possible to override the class file location of a framework class via classmap and autoloader? If yes, then how?
Example: I want to override Zend\Form\Fieldset, so that everywhere in the framework where Zend\Form\Fieldset is referenced, I want it to use my own class file instead of the original.
Motivation: When updating the framework, I want to keep my modifications safe from getting overwritten.
Known alternative: Modify the code in the framework.
Disadvantage: Modification gets lost when updating the framework.
writing the same class (FQCN) at another location is generally a bad idea. This causes two classes which are equally named to live in two separate locations. It's a much better idea to create your own Fielset in your own namespace. Say, Application\Form\Fieldset.
You can extend the ZF2 fieldset by your own. Then reference this new fieldset class and its all much more maintainable.
The downside of this method is you don't automatically use the new fieldset class. You have to reference the Application\Form namespace in every form you use. On the other hand, this makes it much more clear to other users of you code what exactly happens: there are no unexpected consequences using ZF2 code.
The only remark I have to make here is, for what do you need another fieldset? If you think you need that for view helpers, that's not true. You can modify the view helper to render fieldsets without modifying the Fieldset form class itself.
I wish to replace the implementation of System.Web.Mvc.ActionMethodSelector as used by the FindAction method of ReflectedControllerDescriptor, but would like to take advantage of the existing implementation, ideally by deriving from ActionMethodSelector. However, because the class is marked as internal the only way I can see to do this 'properly' is to derive from ReflectedControllerDescriptor and implement FindAction by copying the code from ActionMethodSelector. I wish to avoid this however due to the quantity of code, and potential issues trying to keep it up to date with the framework.
I'm considering the following approaches:
Biting the bullet and copying the code
Using reflection so as to take advantage of the existing implementation
Are there any other approaches that I'm missing, better or otherwise?
I know it is a bit late to answer still I am giving it a try.... :)
I believe that you somehow want to tweak action method selection process in ASP.NET MVC. If my understanding is correct you can make use of custom ActionMethodSelectorAttribute by deriving from System.Web.Mvc.ActionMethodSelectorAttribute. Write your own custom logic in the custom selector and apply it on the top of the action methods. I believe in this way the action method selection process can be tweaked without disturbing the natural process.
If you wish you can visit these links: http://programersnotebook.blogspot.in/2014/02/aspnet-mvc-actionnameselector-and.html, http://programersnotebook.blogspot.in/2014/02/aspnet-mvc-actionnameselector-and_2.html
I'm new to Jena, but when I look at the vocabularies defined with the Jena source (i.e. in directory: jena-2.10.0-Source\jena-core\src\main\java\com\hp\hpl\jena\vocabulary) I see some of the vocabularies create properties and resources using 'ResourceFactory.createProperty()' (e.g. OWL2.java, RDF.java, RDFS.java), whereas others in the same directory use 'ModelFactory.createDefaultModel().createProperty()' (e.g. DC_11.java, VCARD.java, DCTerms.java).
I understand that ResourceFactory is used to create resources and properties without reference to a 'model', but I just want to understand why some of these vocabs choose to create and use a 'model' instance while others choose not to.
Is it just personal style, or is one approach generally recommended over the other (maybe one style is an 'old approach', as I understand Jena has been around a long time)?
I'd like to use both the RDFS and DC_11 vocabs with my code, and obviously define my own app-specific resources and properties, so I'm just trying to understand which approach I should adopt for my own stuff.
That both styles are used is just historical accident. I think these days, I'd probably suggest using the ResourceFactory approach, simply because it avoids the (small) overhead of allocating a model, and the model gives you no real advantages. At some point, we'll probably go back and do some refactoring to just use a single approach in the Jena codebase.
Currently I'm modifying a project that uses xText to parse a custom DSL. I want to add functionality to the generated classes but unfortunately I failed implementing the generation gap pattern. I used this article as a basis:
http://heikobehrens.net/2009/04/23/generation-gap-pattern/
My problem is that we're using a lot of Fragments to customize the org.eclipse.xtext.generator.Generator. It seems I cannot reuse those fragments for org.eclipse.xpand2.Generator.
So in conclusion:
how can I implement the generation gap pattern for the xtext generator
OR how can I use Fragments with the xpand2-Generator
OR is there a third solution that allows me to use fragments and implement the generation gap pattern?
After researching the matter, I'm thoroughly confused.
The generation gap pattern described in the article will work with almost any general purpose code generation framework. Xtext is no exception to this.
Besides that, Xtext offers another nifty solution to fill the generation gap. This is Xbase. But Xbase forces you to tightly integrate with java, so this is not always an alternative.
Consider following steps adding generation gap pattern to the existing Xtext project:
Locate generated file with the gap (with the code fragment you want to write by hand). Let it be e.g. MyClass.
Alter generator so that
the generated file get renamed to the AbstractMyClass.
the abstract keyword get added to the AbstractMyClass class definition.
the gap get moved to a single method.
an abstract method get generated for the gap.
the abstract method get called from the generated code.
Add 'MyClass extends AbstractMyClass' by hand and implement the abstract gap-method
If you have concrete problems with some Xtend2 code, post questions here or in Xtend forum.