in

Emerald Hand

Emerald Hand, Inc. community home page.

This Blog

  • Home
  • Contact
  • About
  • Directory of Computers/Tech Blogs

Syndication

News

I'm back to blogging

Worm in liquid maze

Design and development of information management tools.

June 2006 - Posts

  • First look at the Dojo Toolkit

    I'm evaluating Dojo Toolkit and thinking about abandoning (or rather blending) JSForms for the Dojo. I'm not sure yet if I'm going to do it. I have created JSForms out of necessity, to help me with other projects, but it's not something I have spare time for.

    Before I started with JSForms, I looked at several different projects and documented what I found at similar projects section of JSForms documentation. None of them really satisfied me. I guess I could have tried to join one of the toolkits, but I felt none of them really met my requirements. I found JSOLait and really liked JavaScript OO language extensions it offered, but I don't want to reinvent the wheel. I'd rather use the toolkit that provides all functionality I need than re-write one on my own. I'd like to be able to contribute (or at least extend it for my needs) and there are several things I need from the library (no memory leaks, easy to use generate with XSLT).

    I learned about Dojo Toolkit when it was in 0.1 and it wasn't quite what I was looking for. It might be now. I'm still learning about it and not sure if I'll switch, but I want to share what I know about it so far.

    Dojo Toolkit is a JavaScript library. Well, kinda, it's more than just a library. It provides environment to develop with JavaScript. It has a lot of features, like language extensions.

    What I like

    Free and open source

    First of all it's free and open source. It can be used in any commercial project and all the source code is available.

    Rapidly developed

    There are a lot of people working on the toolkit. Most of them are working on the Dojo part time (when they are not busy with their daily jobs). So releases are not very frequent, but each adds a lot of functionality.

    Recognized and supported

    Dojo Toolkit is slowly gaining recognition. Several big companies (IBM, Sun) extend it. There are tools to work with it (for example Eclipse has a plug-in to help with Dojo development).

    There's a mailing list and an IRC support channel. People are very active, especially on the mailing list. If somebody has a question it is usually addressed quickly.

    Feature Rich

    Dojo Toolkit has a lot of features. It provides classes to work with different data types (arrays, strings, etc), to help with server communication (AJAX, IFrame, etc), and there are a lot of widgets. That's where my main interest lies, widgets. There's a layout manager, WYSIWYG HTML editor, a tree, a menu, a grid, tabs, tooltips and so on. It's very nice.

    AOP events programming

    Dojo uses an AOP programming style to program events. It lets developer to register a function to run before or after any other function in any object. It's a very powerful concept. I wonder what is the performance price... Probably not very large.

    Declarative programming

    Dojo supports declarative style of programming to describe widgets (controls) on the page. When the page is loaded Dojo parses it, and creates and initializes widgets from the HTML or custom tags on the page. This is really cool, but unfortunately it's quite slow. It's good to create common controls for the page, such as a menu or a tab, but if there's a tree, each node is a widget. If the tree is big, it takes a while to load the page.

    What I dislike

    Slow, slow, slow

    Widgets are cool, but slow to load. I designed JSForms tree to handle large trees. Dojo dies pretty quickly as the tree size grows large (There's a new tree version in development. It's supposed to really improve the performance and I want to profile it before I compare).

    Even the Dojo demo page (which I assume is optimized. I mean, it's their demo after all) takes from a second to several seconds to load and initialize different demonstrations.

    Poor documentation

    Documentation issues haunt all open source projects. Everybody likes to write code, but not describe it so that other people could use it. It's not always fun, but it's important.

    API is often poorly documented (by poorly I mean there's often no documentation at all). There are examples, but most are in the form of tests developers wrote to verify that their code works correctly. The Dojo demo page does provide source for the demos. These examples are good starting points, but not good enough to understand how to do advanced things (tests, while advanced, have practically no documentation. It's hard to learn from them).

    I really do hope documentation will improve in time. Until then, I'm glad the project is open source and I can look at the code to figure out how to do something.

    Unstable. Frequent API changes.

    The project is still young. There are a lot of cool things done by the developers, but developers are still trying to figure out the API. Things still break from time to time (although I'm glad there are a lot of tests to help with that problem).

    I don't mind that the project might be unstable or API might change. I bet most of the core is stable and won't change much. In time, more and more parts of the project will mature. Until then I will have to spend more time on the maintenance, if I choose to switch to it.

    Share this post: Email it! | bookmark it! | digg it! | reddit!
    Readability Stats: Word Count: 915; Sentence Count: 70; Grade Level: 6.7, more info...
  • Wiki PIM

    For those who don't know, PIM is a personal information manager. It's a special program to store and manage any type of information on the computer that you might want to reference later. I think computer is the best tool to store any type of information, including personal notes, tasks, and so on. I use it for that purpose and looking back at the time when I used notebook to store my notes (or even worse, random pieces of paper) I can't imagine going back.

    There are a lot of different PIM programs, and I think most of them suck. I'm lucky if program allows me to store notes as a tree (sometimes working with a tree is complicated, such as Microsoft OneNote. I hate clicking 5 times to open a page and simply avoid using the tool).

    But to me tree organization is not enough. It's limiting. I often want to be able to access my notes using different paths. For example I want to reference a page dedicated to a book from the list of books I want to read and from a project page that holds all the materials related to the project, which include the book. How to store these relationships in a tree? A page might have two or more parents. In this case the book might be related to several projects. Good PIMs support custom flags (or other forms of references) and I might be able to mark each book as related to project A and B, but it's not always an answer. I need the PIM to support a graph structure.

    Working with wikis I realized that they organize pages in a graph. Each page can reference any other page or itself. That's what I was looking for.

    I'm not a big fan of the wikitext format, but I can live with it. Sometimes there are limitations with renaming a page (a link to the page will break unless all pages are parsed and the link text is updated), but most wikis have mechanism to overcome this. I started to look around the web and found out I wasn't the first who came up with the idea.

    Initially I thought I will have to use a wiki on a server. However, it would have been an impediment to store quick notes on it. I would need to open a browser, navigate to the page, wait for it to load and so on. Plus I don't trust browsers to enter large amounts of data, such as a long article (I use w.bloggar to write blog posts). Soon I found wikiPad and fell in love with it (well, almost).

    wikiPad is free, open source (runs on Python), stand-alone wiki that runs and stores wiki pages locally. It is designed specifically to organize information and uses the fact that it's a local application to go well beyond what most online wikis have to offer.

    Here's a list of things that make it stand out for me:

    • Dynamic tree view - Next to the page editor there's a tree that shows relationship between all pages. Each page is a node. When a page has several parents (referenced in several places) it is shown as a child node of each page that references it. This is very handy, since now I can have my book shown under each project that references it and under a separate page that lists all books I'm planning to read. It is also possible to see a list of all parents of the page.
    • Custom attributes - Each page can have custom attributes defined in a way similar to how links are defined. Tree has a special "views" node that shows all pages grouped first by the attribute name and then by the attribute value (I use this to have two separate lists of projects that I currently work on and projects I want to work on in the future).
    • Wikiword completion - wikiPad can show a list of existing wikiwords or attributes that start with the current word. It helps me to remember the exact wikiword I was looking for. In addition the program has a dialog that finds pages for the text you enter as you enter it.

    The program is nice, but it isn't perfect. This is a list of things I wish would be better or different:

    • No page history - Among other things, wikis are very useful for version control. In most wikis it's easy to see previous versions of the current page and compare it with the current page. Not in wikiPad. I miss this feature.
    • Limited tree operations - Tree doesn't support add or drag and drop. It might be tricky to define what should happen (since links are embedded and mixed with the page text) and implement, but it would have been useful.
    • No hotkey or single instance - The application can be minimized to the taskbar icons area, but there's no hotkey to open it. I could have created a hotkey to launch the application, but it doesn't support single instance.
    • Flat pages relation - I like how open-ended wiki is, but sometimes it does get in the way (partially due to the way wiki works). For example I can't have "Project/Overview" page and then from "Overview" reference parent page using "../" or something like that. This way I cannot have multiple "Overview" pages that are related to different projects. It's a price I'm willing to pay. As a side note OpenWiking does support both, flat and structured pages location.

    I also want to mention that with a graph structure it's really easy to create a mess out of the page relationships since the wiki is so open. I try to be careful with referencing a page in several places. If I do it I get a chaotic mixture in which it's really hard to find what I need. Most of the time I don't have this problem.

    Alternatives

    It wouldn't be fair to praise wikiPad without talking about alternatives. I have already mentioned that it's possible to just host a web-based wiki on a local server. I don't like that solution because it's sluggish and using browser to enter text can be unreliable. There's a number of wiki application designed to run locally (look at Desktop Wikis at Wikipedia), but most of them have limited support to show relations between wiki pages, such as dynamic tree in wikiPad.

    The only other desktop wiki I found that I found interesting is ConnectedText. It's a shareware wiki with some features that are missing from the wikiPad. It supports inline images and page versions, but I don't like their "tree" with pages (both how it looks, how it acts and it misses some of the wikiPad features, such as custom icon for the node). I like it less than wikiPad. For me, wikiPad parts absent from the ConnectedText are important, but I can live without unique ConnectedText features.

    Share this post: Email it! | bookmark it! | digg it! | reddit!
    Readability Stats: Word Count: 1173; Sentence Count: 69; Grade Level: 8.3, more info...
  • OpenWiking

    OpenWiking is the wiki I decided to use for JSForms. It is derived from OpenWiki, old ASP-based wiki.

    OpenWiki is written in ASP VBScript and can use different databases (Access, MS SQL, Oracle, etc.) to store wiki. While I would prefer .NET, ASP is much more familiar to me than PHP.

    Original OpenWiki was designed to be extensible. It provides facilities to write custom macros to dynamically generate HTML when showing wiki page (table of content for example). It comes with a set of macros and people have written and published more of them.

    To show a wiki page OpenWiki generates XML from the wiki text. It is then transformed using XSLT into HTML. This makes it easy to create custom themes and export.

    OpenWiki supports hierarchical pages ( in addition to flat list of camel case pages. It makes it possible to create pages with the same name for different parent pages.

    The project basically died in 2002. There weren't any updates to it since then and some of the people, including custom macros contributors, decided to revive it. OpenWiking was born.

    It's a new generation of OpenWiki. Developers have added more themes and extensions. The project is still in development. While it's not as active as I could have wished, there are occasional updates to it.

    OpenWiking lacks some features that I would like to see. There's no normal authentication support. It supports Windows Authentication, but not database-driven log-in. On the bright side it does support page-specific permissions through custom attributes.

    I wish there would be more themes, most of them look quite simplistic. This isn't a big problem, since I'm planning to create a custom theme at some point anyway.

    Conclusion

    OpenWiking is not very popular, but I think it's overlooked. It offers a lot of very nice features. It's stable and has a clear separation between logic and presentation, making it easier to customize and theme.

    I looked at the code some and in general it is well-organized and documented.

    The wiki lacks several features (normal authentication, discussion for each page, etc.), but most of the important features are present. You can find it on my wiki server.

    Share this post: Email it! | bookmark it! | digg it! | reddit!
    Readability Stats: Word Count: 367; Sentence Count: 34; Grade Level: 8.0, more info...
    Posted Jun 09 2006, 05:00 PM by Ornus with no comments
    Filed under:
  • MediaWiki

    I have mentioned previously that I researched different wikis for my website and I wanted to share my experience. Today I'll talk about MediaWiki. I was aware of it for a long time (thanks to Wikipedia) and was seriously considering using it. MediaWiki is built on PHP and designed to use MySQL on the backend.

    It is very mature, but in my opinion some of the features could be better implemented. The user base is quite large and releases happen often. I know it is scalable (not that it's important for me right now) since Wikipedia is one of the largest (if not the largest) wikis on the web.

    The biggest problem with MediaWiki, for me, lies with technologies it uses. I'm not experienced with PHP or MySQL and don't really want to learn them right now. It might be easy to use, but in my experience web applications often require me to look at the source code to configure, customize or fix a problem with the application.

    The wiki has export functionality, but it exports in wiki text format. I would prefer something better structured, like XML. It might be possible to export data from generated HTML, but that, most likely, would require writing my own PHP script.

    MediaWiki has a number of useful features. It supports authentication, but number of roles is limited and permissions are set for the whole wiki, not individual pages. At least it's possible to let only registered people edit pages and track changes on individual basis.

    Table of contents is built automatically for the page from headers. The page editor, while better that simple text area, leaves a lot to be desired for, especially from such mature project. There's a good support for image attachments.

    The most unique feature is support for forum-like discussion on each page. I think it's a great idea. Too bad MediaWiki is the only wiki supporting this (as far as I know).

    Conclusion

    I decided not to use MediaWiki. I'm not familiar with technologies it is built on and I probably will have to spend more time trying to customize it than I want to. Export capabilities are also somewhat limited.

    It is a good wiki, probably the best built on PHP. It has nice features, such as authentication and page discussion. It's just not quite what I was looking for.

    Share this post: Email it! | bookmark it! | digg it! | reddit!
    Readability Stats: Word Count: 397; Sentence Count: 28; Grade Level: 8.3, more info...
    Posted Jun 07 2006, 07:52 PM by Ornus with no comments
    Filed under:
Copyright © 2006-2007 EmeraldHand, Inc. All rights reserved.
Powered by Community Server (Non-Commercial Edition), by Telligent Systems