Customizing queryCatalog script in Plone or using reversed chronological order by default - plone

I have been asked to help in tweaking an Intranet done with Plone 4.0.5; one of the requirements is to always (by default) use the reversed chronological order in folder's listings.
I haven't touch Plone since it was at version 2.5; so lots have changed.
Is there any simple parameter/configuration to accomplish this?
Failing that. I have tracked the fetching of the showed items to queryCatalog script inside portal_skins/plone_scripts.
I have customized this script TTW. Later I plan to customize this by means of whatever you recommend (an adapter?, a ZCML? I have yet to study that stuff). What are the best practices these days?
If I have set the 'sort_on' and 'sort_order' keys by hand everything seems to behave as I'd want. But if I use the setdefault method of dicts, then nothing happens, so it seems that an order has been requested.
How can I log inside a script customized TTW?

instead of patching the catalog (which might change sort order in navigation or other places where you don't want/need it) you could
customize the folder-views you're using (eg folder_summary_view)
this might help: http://keeshink.blogspot.co.at/2009/06/how-to-change-plones-default-folder.html
use collections to display items contained in the folder (only a good idea if you need the reverse order just in some folders)
or use one of these addons http://plone.org/products/collective.sortmyfolder
or http://pypi.python.org/pypi/wildcard.foldercontents

For logging:
context.plone_log('My script', 'My message')
You seem to be on the right track otherwise.

Related

Frama-C's extensible printer and projects

I am trying to make changes to the behavior of a function and print the results to a file. The ViewCfg plug-in described in the Plug-in Development Guide does something similar, but I am trying to avoid having to use Ast.get, which ViewCfg uses. I am thinking of extending Printer.extensible_printer which, according to the Frama-C API Documentation, is something I can do if I want to obtain a custom pretty-printer.
However, if I extend the pretty-printer as described in the API docs, unless I'm doing something wrong, I notice that the changes I make take place regardless of which project is set as the current project. I'm using File.create_project_from_visitor to create a new project and Project.set_current to set the new project as the current project before I use the custom pretty-printer.
Is it true that any change made by a class that extends Printer.extensible_printer applies to all projects? I happen to be using frama-c-Aluminium-20160502, which I know is not the latest version.
EDIT: Sorry, I should have made this clearer in the beginning, but I'm not actually making changes to the behavior of a function. I'm reading in the behavior of a function, then based on that, I'm trying to generate as output valid C code that's meant to be read as input by another program.
Regarding AST.get, the only reason I was avoiding it was that it sounds like it gets the entire AST, while I'm only interested in part of it, i.e. behaviors. But if I'm just making things harder for myself by avoiding it, then I'll go ahead and use it.

global settings in sailsjs

What would be a proper way to handle global "settings" in my sailsjs application? The user will want to change those settings via the web front of my app.
I imagine I could use a new model "GlobalSettings" with only one item, but I don't really know if it's a good "MVC" practice.
Since it is based on user input, it has to be stored in a database and therefore storing it in model seems like a right choice to me.
Having just 1 row/collection is completely ok in my opinion, especially in the no-SQL field. But for more reusability and scalability, you might want to consider to actually store each setting in invididual row, that might give you space to expand the usability of it in the future.
In my own opinion, I always find as a web app develops, you will start to realize there are more and more fields that you want the user to setup as their preference, as a good practice to relax the application.
For me I usually setup a meta_data model with name, value, criteria, and some other fields.
For example, when viewing your web page, 'Alice' may want a background color of black, 'Bob' may want a background color of green. Then you can let them modify or insert row into this meta_data collection. Then in your database, you will have
name value criteria
background_color black user_name='Alice'
background_color green user_name='Bob'
and it can be all kinds of values.
of course if you just have one value that can be changed by all of your users, it is probably a good idea to know who updated them. For this you would want to create a trigger, (if you are using a sql database)see trigger in mysql, so that every update on the table will trigger a function that stores what was changed and who changed it in another table
So yes, to answer your question, it is totally ok to have a model to store a value, and don't worry about only have one row, you will have more as you develop your app.
The config/globals.js file seems to be a good place to place a global configuration setting.
For convenience, Sails exposes a handful of global variables. By
default, your app's models, services, and the global sails object are
all available on the global scope; meaning you can refer to them by
name anywhere in your backend code (as long as Sails has been loaded).
Nothing in Sails core relies on these global variables - each and
every global exposed in Sails may be disabled in sails.config.globals
(conventionally configured in config/globals.js.)
Sailsjs.org Documentation - Globals
Alternatively you can use the sails.config object.
Custom Configuration
Sails recognizes many different settings, namespaced under different top level keys (e.g. sails.config.sockets and
sails.config.blueprints). However you can also use sails.config for
your own custom configuration (e.g.
sails.config.someProprietaryAPI.secret).
From the docs
There is also services which is global by default.
Overview
Services can be thought of as libraries which contain functions that you might want to use in many places of your application. For example,
you might have an EmailService which wraps some default email message
boilerplate code that you would want to use in many parts of your
application. The main benefit of using services in Sails is that they
are globalized--you don't have to use require() to access them.
It really depends on what kind of global you are wanting.

Can I delete the SDL Tridion Default Groups?

I've assumed there was something unique or special about the default Tridion groups (e.g. Editor, Chief Editor, etc) because creating a new Publication seemed to get these groups automatically.
I actually see that new publications get all of the groups in its assigned parent upon creation, it's not necessarily because they're default groups.
Can I delete these default groups? Aside from the out-of-the-box workflow options, any reason to leave these in Tridion from a programming or technical perspective?
New Publications outside of an existing BluePrint will pick up the default rights from the default groups. If you don't need any out of the box settings, you should be OK deleting them (but I have never tried, so it may not be possible). In the database they have a special flag (IS_DEFAULT_GROUP).
I tend to use them for controlling rights, and make my other groups members of Authors,and Editors etc so that I get some basic rights out of the box for all publications.
In the original design of R5 security it was possible to delete the predefined groups, and this was intentional. If you are getting a specific message telling you it is not possible, then this constraint must have been added later, presumably as code was re-written for 2011.
The thinking back in R5 was that the predefined groups would offer a good "out-of-the-box" experience, and save people some configuration. (And of course, it offered backwards compatibility with R4.) Other features echoed this: for example, if you create a publication in a blueprint, the Rights of predefined groups are cloned from the parent publication. For groups you've created yourself, this doesn't happen. After all - if you've chosen to go for a custom security set-up it's reasonable to expect you to customise everything yourself, right?
I can't think of a good reason for preventing their deletion. Perhaps someone thought the "custom" approach was just too unfriendly, but I'm speculating. (Anyone know the real reason?)
No, it is not possible to delete a predefined group -- you will always get an error saying as much.
I can't speak as to the reasons for this, but I imagine the fact that they are used for new Publications is at least part of the reason.
You are not required to actually use them, though.

Documentation Generation - What boxes should I aim to tick?

I'm looking at requiring my team to document their code more thoroughly for some major upcoming projects and to make life a little less painful, I am steering towards XML documentation generators such as Sandcastle, Doxygen or Box Live Documenter.
What are the key considerations I should keep in mind when evaluating the best option and what experiences have led you to a particular decision?
For me the key considerations would be:
Fully automated: Can it be set up in such a way so that pretty much
no outside work is required to
create or edit the documentation.
Fully styled: Can the documentation be fully styled so
that it looks great in a wiki or pdf
after it’s generated. I should be
able to change colors, font sizes,
layouts, etc.
Good Filtering: Can I select only the items I want to be
generated. I should be able to
filter the namespaces, file types,
classes, etc.
Customization: Can I include headers, footers, custom elements,
etc.
I found Doxygen could do all of this. Our workflow is as follows:
Developer makes a change to the code
They update the documentation tags right above the code they just changed
We click a generate button
Doxygen will then extract all the XML documentation from the code, filter it to only include the classes and methods we want, and apply the CSS styling we’ve pre-made for it. Our end result is an internal wiki that looks the way we want, and doesn’t require editing.
Extra: We have all our projects in various git repositories. We pull all these down to one root folder and generate the docs form this root folder..
Would be interested to know how others are automating even further..?
Who is paying for the documentation and why? (is the system stable enough, does it add enough value)
Who is going to read it, and why is she not using a more effective communication channel?
(if correct mostly distance in time/place)
Who is going to keep it up to date.
When are you going to destroy it? (Automatically if it hasn't been read or updated in the past three months?)
I mostly prefer better code to make my life less painful, over more documentation, but I like scenario & unit tests and a high level architecture description.
[edit] Documentation costs time and money to write and keep up to date. JavaDoc style documentation has a serious detrimental effect on the amount of code simultaneously visible and might be a good idea for the developers using the code, but not for those writing it.

Drupal 6 - make a module for every block of dynamic information?

I have a Drupal 6 website with about 20 pages. Inside every page, I need to create a lot of widgets with information either stored inside the database or from external web services. Most of the time, a "view" (from the view module) is just not enough to solve the requirement.
Up until now, any time I need such a widget, I create a new module which implements hook_block. Then, I drag and drop this new module inside the panel I want. I will need to create about 20 modules. This works pretty good. However, I'm not sure if this is the correct-drupal-strategy and I would love to receive some feedback from experienced Drupal developers.
A module can expose as many blocks as you want (in theory, admin/build/blocks will teach you otherwise ;)).
Have a look at the documentation of hook_block(), you just need to extend yours to return multiple block infos and then decided which one to show based on the $delta.
So you don't need 20 separate modules, maybe 2-3 and group the blocks somehow together because just a single module might be hard to maintain. The thing is that every single module makes your site a tiny bit slower (at least one more file to load, module_implements() needs to loop over every module for every hook and so on).
Without more information , it's hard to give any better advice. Maybe you could expose your data to views, or write a views plugin to display it in the way you want it, or...
Although Berdir's answer is pretty good, I'm impressed there's no link to any documentation in it. hook_block is meant for several blocks, and they can share functions that build their content. The API page is good, the example it gives defines two blocks at once.
You should notice each defined block has a delta (a key in the $blocks array). You can have dynamic deltas and use values in it to fetch data (passing a nid or uid and getting related content, for example).

Resources