ROTR

I wanted to make sure search terms were highlighted when searching for items in SPHYRA, so I set off to find something that would help me do so. I came across Trac's implementation, which uses JavaScript and is based on the one here.

In those cases, the code is used to highlight search terms that were entered by the user in a referring page, such as a Google search result page. What I desired was a way to specify my own words, and only highlight within a certain area.

Here's the first pass of a ToscaWidgets based widget I came up with for doing this.

• Widget subclass
• JavaScript
• CSS
• Currently used by find_item in sphyra.controllers.tag and its corresponding template.

I finally had the time to fiddle around with ToscaWidgets inside Pylons recently, and came up with a top bar for SPHYRA that is driven by information in a Schevo database.

• The widget class takes care of converting parameters given to the widget to data structures usable by the Genshi template.
• The widget template converts it into a fairly simple navigation bar.
• The controller base class populates a widget using the database and makes it available to every controller.

Notes

Some notes for my own edification, as I learn this from the ground up as it's being developed. (Thanks, Alberto, et al, for doing all the hard work!)

Creating a simple widget class usually involves the following:

from toscawidgets.core import Widget

class MyWidget(Widget):

    # 'params' are the valid keyword arguments that can be passed to
    # __init__ and __call__
    params = [
        'abc',
        ]

    # 'template' is 'templatetype:templatename'
    template = 'genshi:myapp.widgets.templates.mywidget'

    # Set default values for parameters.
    abc = 123

    # When ToscaWidgets prepares a dictionary to be sent to the
    # template specified above, it calls update_params against
    # that dictionary.  Use update_params to modify the parameters
    # set on the widget to a form that is 'massaged' enough for
    # the template to make proper use of.
    def update_params(self, d):
        d['abc'] = d.get('abc', 0) * 2

To include a widget in the final HTML, given that c.widget is an instance of a ToscaWidget:

${c.widget}

To create a new widget based on an existing one, just call the widget instance with the parameters you want to override:

c.widget = c.widget(some_param=some_new_value)

Questions and thoughts

Is there a way for the TopBar widget to include an image resource for the logo, and then be configured in such a way that it is used as the default unless overridden by a parameter that contains the URL for a different image?

I'd also like to get my TopBar-specific CSS packaged up with the TopBar widget itself, and simplify it a little more.

I'm sure I'll figure these out in time but if anyone responds to this I'll give them a free cookie. (*)

(*) Cookies not guaranteed to be edible. Cookies may consist of electronic transactions already made in the course of reading this text.

(Edit 2007-12-11: I no longer use EveryDNS or have a need for this project, so this is one for the deadpool!)

Earlier this month, EveryDNS was under a DDoS attack that put it out of service off and on for several consecutive days.

I currently use EveryDNS for primary and secondary DNS service on all of the domains I am responsible for. It's easy to use, was quick and convenient, and took worries away from a group that was accustomed to using BIND for DNS service.

It became clear to me, and to the other decision makers I work with, that the DDoS attack meant that we should look again at how we distribute our DNS service. Another concern I had regardless of the DDoS attack, is that we are working on rolling out a service we sell at a faster pace, and it would be beneficial to have a handle on being able to easily provide authoritative DNS answers about new subdomains.

Whatever we do though, it must be something that doesn't bring back the bad memories of manual BIND configuration file editing, and doesn't bring back the bad memories of numerous BIND security holes over the years.

It must also be something that is easy for sysadmins to manage, preferably using a web browser and a simplified interface similar in nature to EveryDNS's.

Finally, it might as well use Schevo if it's direct and feasible to do so, and serve as a testing ground for the other Python packages I've started using, including Pylons and ToscaWidgets.

All of this culminated into the creation of the dym project. Because the initial experiment to drive a DNS server based on a Schevo database was successful, I continued the project and will be writing about it as I write it.

Questions, comments, code, and curiosity are welcome! :)