Axant Tech Blog

Rehearsing new ACR look and feel

Tuesday, November 24th, 2009 | Opensource, Web | Comments

As some turbogears projects are starting to use ACR as their CMS library we received the first few requests by real users and the most prominent one is to have a better administrative section. Currently administration section is implemented by using the great tgext.admin and sprox, even if those are really good to quickly implement a CRUD section they might not couple very well when a more interactive and advanced user experience is required.

So a transition phase that will end with a totally new administration section for ACR has been started, currently the system implements a new user interface still using the same backend as before to handle the operations, but on the long time the backend itself will be rewritten to handle easier contents creation and management. In the mean time also support for multi-language, versioning and authors has been added.

Tags: acr, cms, turbogears

Injecting static content in TurboGears

Saturday, November 21st, 2009 | Web | Comments

Something that you usually need to do when providing a library or a reusable wsgi application is installing static data with the library itself.

This can be quickly performed by adding something like

package_data = {”:['*.html', '*.js', '*.css', '*.png']}

to your setup.py

But then how can we let our turbogears application serve that?

• For html files (genshi templates) the solution is quite simple, you can just expose them by using @expose(’librarypackage.templatesdir.template’). For example supposing we are installing libcool with its templates in libcool/templates you can do @expose(’libcool.templates.index’)
• For js and css files you can add them to your pages by creating a tw.api.JSLink or tw.api.CSSLink object. Just create inside your library something like: cool_js = tw.api.JSLink(modname = __name__, filename = ’static/cool.js’) and then place in the controller exposing the view where you want to use that js file cool_js.inject()
• Exposing images can be more complex, you have to declare a widget which will render the img tag by using ToscaWidgets resources exposure.
  

  class IconLink(tw.api.Link):
      """
      A link to an icon.
      """
      template = """<img src="$link" alt="$alt" />"""
  
      params = dict(alt="Alternative text when not displaying the image")
  
      def __init__(self, *args, **kw):
          super(IconLink, self).__init__(*args, **kw)
          self.alt = kw.get('alt')

  then you can create one IconLink for each icon in your library with something like: parent = IconLink(modname=__name__, filename=’static/icons/parent.png’, alt=’Up’) and inside your views you can place the icon by doing ${parent.display()} . This will add the image by exposing it from inside the static directory of your library package. Remember that you need to add an __init__.py inside the static directory and its subdirectory if you want setuptools to correctly install the static files.

Tags: setuptools, toscawidgets, turbogears

Syslog(3)

Sunday, November 8th, 2009 | Uncategorized | Comments

Recently Diego complained with me about the mod_accesslog I quickly drafted for Feng.

I didn’t check much about supporting bare files log but I just used syslog since that’s what I use for all the services that support it. Luckily he fixed the glitches I left since his usage patterns are quite different than mine.

Bare file logging usually is used by default in certain applications mostly because:

• You want to keep per-usage/per-user/per-deploy logs (think certain apache deploys)
• Your application doesn’t support syslog at all
• You didn’t knew about syslog and/or your logger daemon is a pain to configure
• You are fond of logrotate and/or you like to get your disk full of historic data

Having syslog based logging usually has some disadvantages over bare file just because you have to configure both the logger and the application, but gets quite handy when you need to tune all the logs in particular ways like sending them over the network or having the server automatically notify critical issues over email.

I really dislike bare file logging, mostly because I’m quite fond of metalog (so I’m not afraid of configuring my logger) and while deploying gluster for Stack! Studios render farm I really hated having those stupid bare files around while the rest of the well behaving applications would had their log correctly routed from the storage nodes to the almost centralized logging facility.

Having proper centralized logging is surely useful when you have to admin a system with a large number of applications, but for a big and increasing number of nodes it gets a boon.

Moreover if you plan to have read-only netbooted root images and almost zero local storage (more on the crazy solution I’m baking with bartek at Stack! could appear sooner or later) you really start to love it (and have a love-hate relationship with syslog-ng for its less than crystal clear documentation)