Plone Dexterity supports the definition of the content-type schema either through an interface (using zope.schema for the definition) or through an XML file. What is the preferred/recommended way?
In addition: is there documentation of the XML dialect used for defining a schema (models/mytype.xml) ?
This presentation appears close but not complete.
I personally much prefer the zope.schema route; I can, if I really wanted to, vary the interface attributes dynamically with python, while the XML definition is of course static.
Also, note that to register adapters and views against an XML-defined schema, you need to pull it into python code anyway:
from plone.dexterity import api
class IMyXMLDefinedType(api.Schema):
api.model('my_xml_defined_type.xml')
The XML dialect is part of plone.supermodel package; I was not able to locate any documentation beyond the source code.
I prefer an interface over an xml model. Partly that is because I prefer Python over XML. Partly it is because you cannot do some things with the XML. For example, if you want to register a field as searchable, with collective.dexteritytextindexer, you (currently) cannot set this in the Plone interface, so you will have to use Python code and therefore an interface. But Martijn shows in his answer that you can use api.model in an interface to refer to an xml file, so maybe that would be a way around it if you really want to.
I'm going to contribute to the mess by saying there is no hard and fast answer.
With simpler content types, or early in the development of more complex ones, I'm often oriented towards the supermodel XML because of how closely it works with the dexterity TTW editor. It allows me to work with a client with very rapid feedback on what they want from their content type.
Sometimes I'll even move into file system development of some features while still having the fields defined in the FTI via supermodel.
However, with more complex content types, you're nearly certainly going to hit something you can't do via supermodel alone. At that point, I usually translate to schema — and that's typically pretty easy to do.
Ideally, if you're doing a lot of dexterity development, you should probably be able to shift pretty easily back and forth. They're just different ways of representing the same objects and attributes.
Related
I'm using the qdbusxml2cpp tool to generate a D-Bus adaptor class for my D-Bus server. However, it has the following drawbacks:
Code is generated once, and then you're not supposed to modify it. But what if we have to make changes (see below) and then the XML changes (in a backwards compatible way, of course)?
It is assumed that the "adaptee" has the exact same functions and signatures as the D-Bus interface. In my case, that's not exactly true, e.g. some methods are named differently. Because the generated code uses QMetaObject::invokeMethod, this is only detected at runtime. And we can't sensibly modify the generated code if we might need to regenerate it in the future.
It would be much nicer, in my opinion, if qdbusxml2cpp would generate an abstract class, just a header, where all methods are pure virtual. Then I can write an implementation of that class that simply calls the right methods on the adaptee, without going through the Qt metatype system. This solves both problems:
If the XML changes, we just regenerate the header. Now the compiler will complain until we implement the new interface correctly.
We have the freedom to call whatever functions we like on the "adaptee" class, instead of maintaining the exact same signature as in the public D-Bus interface.
I couldn't find any tool or qdbusxml2cpp fork that does the above. Before I write it myself, are there any problems with the above approach that I might be overlooking, design-wise or technical? Perhaps limitations of the metatype system related to abstract classes or pure virtual functions?
Note that I need this to work not just with methods, but with properties and signals as well.
I've also considered writing an "intermediate" adaptor that wraps the "adaptee" and offers the exact interface that the D-Bus adaptor expects, but the D-Bus adaptor would still be using the metatype system and runtime checks. Surely we can do better.
As you've discovered, there's no way to do what you want with qdbusxml2cpp directly. Which means that we have a few options here, some that you've already listed out:
It would be much nicer, in my opinion, if qdbusxml2cpp would generate an abstract class, just a header, where all methods are pure virtual.
There doesn't seem to be anything terribly wrong with this, although some tools/IDEs may not play nicely with it. One downside to this is that whenever something changes, you would have to ensure that you update all parts of the C++ source as well, not just your header, e.g. if there is boilerplate that has to change whenever a new method is added.
Code is generated once, and then you're not supposed to modify it. But what if we have to make changes (see below) and then the XML changes (in a backwards compatible way, of course)?
Depending on how well the code generator works, I've sometimes found it easier to simply use the generated code as a starting point and then simply modifying it from there. Most of the chages are generally pretty simple.
One other option that you could do is to use a different library to do the DBus communications.
dbus-cxx
dbus-cpp
dbus-cplusplus
I use(and maintain) dbus-cxx; there is a tool included(dbus-cxx-xml2cpp) that generates adaptee classes that are similar to the output of qdbusxml2cpp in that the adaptee class simply calls a different class that handles the actual response. The downside is that the xml2cpp tool is not that smart, and will not always output correct code. And to use dbus-cxx in a Qt application, you need to turn off the Qt keywords. However, it does have the advantage of using templated functions, so if your signature is incorrect you will get a compile error.
Unfortunately, there isn't really a good "right" way to do this, so I'm afraid that I don't have a "Do it this way" answer.
Question:
Is there a static way to reliably determine the type contained by a type derived from CollectionBase, using Reflection or Microsoft.Cci?
Background:
I am working on a code generator that copies types, makes customized versions of those types, and converters between. It walks the types in the source assembly via Microsoft.Cci. It prints out source code using textual templates. It does a lot of conversion and customization, and tosses out code that I don't care about.
In my resulting code, I intend to replace List<T> everywhere that a CollectionBase, IEnumerable<T>, or T[] was previously used. I want to use List<T> because I am pretty sure I can serialize it without extra work, which is important for my application. T is concrete in every case. I am trying not to copy CollectionBase classes because I'd have to copy over the custom implementation, and I'd like to avoid having to do that in my code generator.
The only part I'm having a problem with is determining T for List<T> when replacing a custom CollectionBase.
What I've done so far:
I have briefly looked at the MSDN docs and samples for CollectionBase, and they mention creating a custom Add method on your derived type. I don't think this is in any way enforced, so I'm not sure I can rely on that. An implementor could name it something else, or worse, have a collection that supports multiple types, with Object as their only common ancestor.
Alternatives I have considered:
Maybe the default serialization does some tricks that I can take advantage of. Is there a default serialization for CollectionBase collections, or do you generally have to implement it yourself? If you have to do it yourself, is there some reliable metadata I could look at in order to determine the types? If it supports default serialization, does it rely on the runtime types of the items in the collection?
I could make a mapping in my code generator of known CollectionBase types, mapped to their corresponding T for List<T>. If a given CollectionBase type that I encounter isn't in the list, throw an exception. This is probably what I'll go with if I there isn't a reliable alternative.
I'm still not sure enough about what you want to do to give advice. Still, do your CollectionBase-derived classes all implement Add(T)? If so, you could look for an Add method with single parameter of type other than object, and use that type for T.
I am creating a web application that will need to send a variety of emails out to users. Instead of hard-coding the contents of the email in the app, I want to use a template stored on disk and replace tokens in it (ex. "Hello, %%FirstName%%!") with the actual data. I have some experience with creating XSLT templates, but since the data isn't naturally in XML format this may not be the best fit. Is there a better template tool in .NET?
Note that I prefer one built in to the language but I'd consider add-ons too.
Thanks,
Graham
I have personally use Spark. Its an easy to use text templating library (below is an example of Spark syntax)
<var names="new [] {'alpha', 'beta', 'gamma'}"/>
<for each="var name in names">
<test if="name == 'beta'">
<p>beta is my favorite.</p>
<else/>
<p>${name} is okay too I suppose.
</test>
</for>
It even comes with a sample code for email text templating which you could look at on github.
You may want to take a look at MVCContrib. They have an e-mail template system IEmailTemplateService that uses Views to render the actual e-mail message which gives you access to a lot of features, including different view engines. If you are not in an MVC environment, you could possibly still extract some useful tricks out there.
I am using NVelocity for that, and I find it's very flexible and easy to use. It not only allows you to replace tokes, but it also includes sort of a programming language, e.g. for conditionals (if) and loops (for, foreach).
The original project seems to be dead, but there is a fork maintained by the Castle project.
Of course there are lots of other, alternative template libraries (stringtemplate seems to be popular), as you can see in this question I asked some time ago.
Our Flex app would like to work with requests and responses as object graphs (nothing unusual there) e.g. response becomes the model of some view, and would be a structure with several layers of nesting.
** Now, ideally we would like to use the same client (and server) side objects for different message formats e.g. XML and AMF, and have a pluggable serialization/de-serialization layer (!)
AMF has serialization and matching of client to server using
[RemoteClass(alias="samples.contact.Contact")]
but it seems there is no equivalent for XML.
I am (somewhat optimistically) looking for a neat way of serializing the object graph to XML, to send through a HTTPService from the client.
For responses, the default 'object' and 'E4X' provide some de-serialization. This is handy, but of course we don't have the niceties of unpacking the XML back into specific AS classes like we do with AMF.
Any suggestions?
(did have one idea come through about wrapping/casting object as XML or XMLList - this does not seem to work, however)
Update:
Both these libraries look useful, and I will very likely use them at some point.
For now, I really need the simplicity of re-using the metadata set for the AMF3 serialization which we are using in any case ([RemoteClass],[Transient])
.. so the best option at the moment is AMFX - used Flex Data Services for AMF transfer using XML - classes in mx.messaging.channels.amfx package - only drawback at the moment is any Externalizable class is transformed into a Hex byte stream - and ArrayCollection is Externalizable! (hoping to workaround by serializing the internal Array in a subclass ..)
Hope that's useful to someone ..
Regarding the Xml serialization I can give you a starting point (as biased as it may be, though :D).
I am working on a project that allows for automatic conversion of AS3 objects to and from xml. It basically uses annotations on the model objects you use for communication in order to construct the xml structure or populating an object from xml.
It is called FlexXB and you can check it out at http://code.google.com/p/flexxb/.
I started this project cos I got into the same issues at work (namely I have a server that communicates through xml) and I hoped it be of use to someone else.
Cheers,
Alex
Yet another project: FleXMLer (http://code.google.com/p/flexmler/).
It has both the straightforward attitude of asx3m where you can just call:
new FleXMLer().serialize(obj);
Or you can customize XML element names, skip elements and tweak the way arrays and hash tables are serialized.
Would appreciate your input.
checkout asx3m project at http://code.google.com/p/asx3m
It's an AS3 port of Java XStream serialization library and works pretty well.
I made it because I had to connect to a server platform that used XStream for exchanging data objects and put a lot of work in it.
It can be extended to serialize AS3 objects to any format (JSON for example) and could leverage power of user defined metatags.
Cheers,
Tomislav
There's a library including JSON available from Adobe, too. And since ActionScript is a superset of JavaScript ... and JSON is increasingly supported cross-framework ...
I am VERY new to ASP.NET. I come from a VB6 / ASP (classic) / SQL Server 2000 background. I am reading a lot about Visual Studio 2008 (have installed it and am poking around). I have read about "reflection" and would like someone to explain, as best as you can to an older developer of the technologies I've written above, what exactly Reflection is and why I would use it... I am having trouble getting my head around that. Thanks!
Reflection is how you can explore the internals of different Types, without normally having access (ie. private, protected, etc members).
It's also used to dynamically load DLL's and get access to types and methods defined in them without statically compiling them into your project.
In a nutshell: Reflection is your toolkit for peeking under the hood of a piece of code.
As to why you would use it, it's generally only used in complex situations, or code analysis. The other common use is for loading precompiled plugins into your project.
Reflection lets you programmatically load an assembly, get a list of all the types in an assembly, get a list of all the properties and methods in these types, etc.
As an example:
myobject.GetType().GetProperty("MyProperty").SetValue(myobject, "wicked!", null)
It allows the internals of an object to be reflected to the outside world (code that is using said objects).
A practical use in statically typed languages like C# (and Java) is to allow invocation of methods/members at runtime via a string (eg the name of the method - perhaps you don't know the name of the method you will use at compile time).
In the context of dynamic languages I haven't heard the term as much (as generally you don't worry about the above), other then perhaps to iterate through a list of methods/members etc...
Reflection is .Net's means to manipulate or extract information of an assembly, class or method at run time. For example, you can create a class at runtime, including it's methods. As stated by monoxide, reflection is used to dynamically load assembly as plugins, or in advance cases, it is used to create .Net compiler targeting .Net, like IronPython.
Updated: You may refer to the topic on metaprogramming and its related topics for more details.
When you build any assembly in .NET (ASP.NET, Windows Forms, Command line, class library etc), a number of meta-data "definition tables" are also created within the assembly storing information about methods, fields and types corresponding to the types, fields and methods you wrote in your code.
The classes in System.Reflection namespace in .NET allow you to enumerate and interate over these tables, providing an "object model" for you to query and access items in these tables.
One common use of Reflection is providing extensibility (plug-ins) to your application. For example, Reflection allows you to load an assembly dynamically from a file path, query its types for a specific useful type (such as an Interface your application can call) and then actually invoke a method on this external assembly.
Custom Attributes also go hand in hand with reflection. For example the NUnit unit testing framework allows you to indicate a testing class and test methods by adding [Test] {TestFixture] attributes to your own code.
However then the NUnit test runner must use Reflection to load your assembly, search for all occurrences of methods that have the test attribute and then actually call your test.
This is simplifying it a lot, however it gives you a good practical example of where Reflection is essential.
Reflection certainly is powerful, however be ware that it allows you to completely disregard the fundamental concept of access modifiers (encapsulation) in object oriented programming.
For example you can easily use it to retrieve a list of Private methods in a class and actually call them. For this reason you need to think carefully about how and where you use it to avoid bypassing encapsulation and very tightly coupling (bad) code.
Reflection is the process of inspecting the metadata of an application. In other words,When reading attributes, you’ve already looked at some of the functionality that reflection
offers. Reflection enables an application to collect information about itself and act on this in-
formation. Reflection is slower than normally executing static code. It can, however, give you
a flexibility that static code can’t provide