If I'd like to make a content type folderish in Plone, when is it better to use ATFolder vs BaseFolder?
You can use Archetypes BaseFolder when you don't want/need all of the ATContenTypes additional features and metadata, so you will get a lightweight object, but commonly using ATFolder is a better/mainstream choice.
Apart of that: starting from Plone 4.3 is better to switch to plone.app.dexterity framework and use that type of folders.
AFAIK, the main difference between the two classes is that ATFolder subclasses from BaseBTreeFolder, whereas BaseFolder does not. This means that ATFolder is much better suited to holding a very large number of child objects.
Also, ATFolder has
It's worth noting that most of the ATFolder logic now comes from plone.app.folder
Related
My requirement is to use some kind of metadata system for the entities we use, but extensible, meaning that we need to support some kind of custom metadata additionally to querying for properties and methods. The standard Type/TypeInfo classes are useful to some extent, but they cannot be customized to add specific properties to support various patterns we have: tree nodes, master-detail, and other.
Kephas.Model provides a complex infrastructure for supporting such cases, including advanced features like mixins and dimensions, but this is however a bit too much for our system. We need something more lightweight for the code-first entities we have.
Is there a suggestion about what can we use for this kind of requirements? I noticed the Kephas.Reflection namespace, and this seems like a proper candidate, but I am not sure how to use it properly.
That's right, Kephas.Runtime namespace provides a lightweight extensible metadata through the base IRuntimeTypeInfo interface (in Kephas.Core package). There are mainly two ways of accessing it using extension methods:
// get the type information from an object/instance.
var typeInfo = obj.GetRuntimeTypeInfo();
// convert a Type/TypeInfo to a IRuntimeTypeInfo
typeInfo = type.AsRuntimeTypeInfo();
From here on you can manipulate properties, fields, methods, annotations (attributes), and so on, typically indexed by their names. A very nice feature is that IRuntimeTypeInfo is an expando, allowing adding of dynamic values at runtime.
Please note that IRuntimeTypeInfo specializes ITypeInfo (in Kephas.Reflection namespace), which is the base interface in Kephas.Model, too. You are right that Kephas.Model provides a more complex functionality which might make sense for a more elaborate metadata model, including entities, services, activities, and whatever classifiers you can think of, as well as loading the model also from sources other than the .NET reflection (JSON, XML, database, so on).
Another aspect is that up to version 5.2.0, the IRuntimeTypeInfo would be implemented by the sealed RuntimeTypeInfo class. Starting with version 5.3.0, it will be possible to provide your own implementations, which can be more than one.
I want to use realm and I dont know whats so different
Dynamic framework version and static framework version of realm.
(which one is more popular in usage?)
Is anyone can describe a difference with 'easy' words ??
Thanks
It is described here: https://realm.io/docs/java/latest/#dynamic-realms
But the main difference is that a DynamicRealm is not type-safe and does not enforce your schema. Everything you are specified using Strings, whic means they are slower and more unsafe than the static Realm that uses the type system. So unless you are dealing with really dynamic data or migrations I would encourage you to stay with the static Realm. That way you get the full benefit of a statically typed language like Java, less bugs and faster code.
I've been using Object as a way to have a generic associative array (map/dictionary) since AS3/Flex seems to be very limited in this regard. But I really don't like it coming from a C++/Java/C# background. Is there a better way, some standard class I've not come across... is this even considered good/bad in AS3?
Yes, Actionscript uses Object as a generic associative container and is considered the standard way of doing this.
There is also a Dictionary class available, flash.utils.Dictionary.
The difference is that Dictionary can use any value as a key, including objects, while Object uses string keys. For most uses, Object is preferred as it is faster and covers the majority of use cases.
You can see the details on Object here: http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/Object.html
and Dictionary here: http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/utils/Dictionary.html
and the differences between them here: http://livedocs.adobe.com/flex/3/html/help.html?content=10_Lists_of_data_4.html
I'm afraid there's no native alternative to Object or Dictionary for maps and other structures. As for standard, well, it depends on how one defines standard, but there are a couple of known libraries that you might like to check out if you look for Java style collections.
Like this one:
http://sibirjak.com/blog/collections/as3commons-collections/
Also, you could take a look at this question, that has links to a couple of ds libraries (including the above one).
Collections in Adobe Flex
I wouldn't say using Objects is either good or bad practice. In the general case they are faster than any Actionscript alternative (since they are native), but less featured. Sometimes the provided functionality is good enough. Sometimes, it's a bit bare-bones, so something more structured could help you getting rid of lower level details in your code and focusing in your "domain logic", so to speak.
In the end, all of these libraries implement their data structures through Objects, Dictionaries and Arrays (or Vectors). So, if the native objects are fine for your needs, I'd say go with them. On the other hand, if you find yourself basically re-writting, say, an ad-hoc Set, perhaps, using one of these libs would be a wise choice.
I was toying with the idea of allowing module to with a class in a properties file ; something like
availableModules.properties
Contact=org.addressbook.ContactMain
Business=org.addressbook.BusinessMain
Notes=org.addressbook.Notes
...
My framework will use reflection to instantiate the relevant modules, and thereafter call methods on the relevant base classes, or pass the objects as parameters as required.
Is the above a good place to use reflection?
Are there any best practices on where to use reflection already posted on SO (I couldnt' locate one)? Could we start a list along those lines with any responses posted here?
EDIT
Here's another example of the kind of scenarios I have in mind.
Some core code needed to determine the point of call.
One application I saw achieved this by using reflection, another application used an exception. Would you deem the former to be a recommended scenario where reflection may be applied?
For a great framework supporting your idea have a look at the IOC container of the spring framework.
Is the above a good place to use
reflection?
I'd say no. If you want to do this kind of thing, you should probably be using one of the (many) existing mature frameworks that support Inversion of Control aka Dependency injection. Spring IOC is the most popular one, but there are many others. Google for "ioc framework java".
Underneath the hood, these frameworks most likely use reflection. But that doesn't mean you should reinvent the wheel.
I usually used reflection if I want to dynamically use a class which information (assembly name, class name, method name, method parameters, etc) are stored in a string (text files or database).
For example: a compatibility layer between scripting objects (like strings, arrays) or scripting engines( eval() ,readFile() etc.).
Without more context, I'd have to say interfaces as well. Consider that you can represent a function or delegate as an interface with a single method and that abstract classes are just interfaces with some methods potentially already implemented.
That said, it really depends on what you're trying to accomplish. Interfaces lend themselves to cases where you have lots of objects with a common interface but potentially varying implementations. If you are, for example, designing a very simple callback system for plugins (i.e.: let the plugin hook certain events in the host application) then delegates are probably simpler and sufficient for your needs.
Also keep in mind that if you do go with interfaces, you'll probably need some way for the host to instantiate instances. The easiest way to do this is by registering a delegate with the host under some unique name.
Abstract classes are only useful if you want to use interfaces and provide a default implementation of some things. A better solution in that case is to have an actual interface instead, and provide the default implementation as a mixin.
Interfaces have my vote. That way, as long as you define the interface any developer will be able to write something compatible fairly easily without you having to distribute too much code to them.