We have some plone sites that include the getRawQuery method, and at others it is just available getQuery method.
If I grep the whole codebase of Plone searching for getRawQuery I couldn't find it.
After some research I saw that getRawQuery is mapped into this method but I don't know how it is done..
Can someone please explain it?
Archetypes generates a get[fieldname], getRaw[fieldname] and set[fieldname] method for each field in the schema, mapped to the field's get, getRaw, and set methods respectively.
Hi Davi, thank you for the response!
Could you please point me where the magic happen in the code?
thank you
@hvelarde
Came over the same problem with collective.plonetruegallery. It does not work with collections anymore when using dexterity standard types via plone.app.contentypes:
Module collective.plonetruegallery.galleryadapters.basic, line 155, in cooked_images
Module collective.plonetruegallery.galleryadapters.basic, line 143, in retrieve_images
Module collective.plonetruegallery.galleryadapters.collection, line 22, in getImageInformation
AttributeError: getRawQuery
There is also an interface mismatch in collective.ploentruegallery
ICollection from plone.app.collection vs. ICollection from plone.app.contenttypes
that hides the getRawQuery problem - so it is not obvious.
The big questions are:
By the way there is no interface specification behind ICollection. IMHO there should be one to avoid such problems.
Guidance needed
Volker
I just added a couple of PR on master and 1.1.x branch to solve this issue:
Thats one possibel way,
but after reviewing the code of collective.plonetruegallery I noticed some other problems with dexterity collections and PTG which will not be cured by mimicking the old AT behavior in plone.app.contenttypes. So I fixed the problems in collective.ptg.
Also I may rise the question if it is fruitfull to write legacy code to emulate the old AT behavior. IMHO the better way would be to define clear interfaces for the dexterity types and change the third-party software to fit to this new interfaces.
The migration to Plone5 will nevertheless see every developer of third party code dig into their code, so they may also use a new an clear API.
Volker
IMO you have to handle DX and AT in addons separately anyways - therefore my mild opposition to @hvelarde fix in plone.app.contenttypes.
i've done an example in plone.app.event, where browser views access the DX/AT objects via an IEventAccessor adapter, which unifies access to underlying objects. that's one way of doing it...
example:
we have had an API in Archetypes for accessing content type objects for over 10 years; probably it was not the best, for sure it can be enhanced, but instead we just throwed it away without any warning when we implemented plone.app.contentypes in Dexterity.
you want add-on developers to patch bad design decisions, on different ways, on every single add-on, using adapters? is that what you're proposing?
you think 2 lines of code on plone.app.contenttypes is worst than an adapter on dozens of add-on packages?
why make it simple if we can complicate it, right?
guys, these are the kind of things that make people mad… or just simply sad; seems we don't learn from our past mistakes; and after all we still ask ourselves why people is looking away for other solutions.
seriously, we need to think before coding; we need to plan for the long run... time now for my favorite Abraham Lincoln's quote (yes, again):
Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
resuming, IMO:
please @hvelarde let's not characterize Dexterity work as being "without any warning"... of course let's improve things but let's also avoid inflammatory accusations
@tkimnguyen my message doesn't contain any inflammatory accusation; my message was carefully written trying to avoid misunderstandings; most of the time I use "we" instead of "you", because this is a community work.
but, yes, let's face it, my message is hard; and is hard because we don't want to keep dealing with this kind of problems.
sometimes we spent many hours to discover these issues; this cost us time and money, both things that we are short of; this causes stress and frustration also.
and all of this can be avoided if we think before acting.
yes, I'm talking about good old deprecation warnings that were so common on the old days.
I understand your concerns and maybe there is a way to fix these problems in a sane way, without polluting the core API. Maybe some generic middleware... The accessor adapter pattern shown above is one way to solve this. Or simply drop AT support in a new major release of your addon, if this is an option for your client projects.
Dexterity is a major change in the content type framework. IMO, there is no easy way to have a modern content type framework and support the old AT API without some middleware.
I am personally happy about a cleaner API, like:
no need to use getter and setter to get/set Archetypes properties. Plain pythonic attribute access (except that you have to adapt DX behaviors sometimes)
Favor of Python datetime over Zope DateTime (actually not everywhere - effective/publication dates are still DateTime, IIRC)
Dropping methods like getQuery with a misleading name, where not the query is returned but a result set.
That doesn't mean that your argument is not a valid one. But I'm against of implementing unpythonic API methods into core, just to have maximum backwards compatibility. There must be other ways doing it, like mentioned above. And there must be some people who step in and work on that.
Also, you can still use Archetypes in Plone 5.
I still fail to understand what getRawQuery did, and why it is impossible to get this information in another way.
