DonationCoder.com Software > MEWLO Web Framework
Mewlo Web Framework Blog
mouser:
Mewlo Web Framework Blog Entry #4 - October 14, 2013 - A First-class Addon/Plugin/Extension System
At the end of my last Mewlo blog entry I talked about the central role of an addon/plugin/extension system in Mewlo, and the idea that it would be a natural first structure to start coding.
There are very good reasons to start with an addon/plugin/extension system. First and foremost because it makes it easier for other coders to start independently writing drop-in code packages, and makes it easier to keep these updated and integrated. But I think another key benefit is that it brings into sharp relief early in development the need to craft an API to interact with the rest of the system. The earlier we force ourselves to view the system as an API, the better.
What exactly should the addon/plugin/extension system for a web framework do? What features does it need to have?
Let's start by restating briefly the main goal of a (web) framework. The goal is to provide a base upon which custom coding can be done. A framework enables coders to avoid re-writing the same structures and code for each new project, and provides a well-organized and easy-to-maintain structure that can be extended.
So it should come as no surprise that all non-trivial frameworks have facilities for adding and integrating 3rd party extensions.
For web frameworks, we can distinguish two aspects of how such extensions work:
First, we can look at the actual API provided for interacting with extensions, and how they communicate with the rest of the framework. Here we find generally quite robust implementations.
Generally one sees a signaling system, where components can register to receive signals when certain events occur, and can register their own signals that listeners can subscribe to. A signaling system is a key way to let modules interact without requiring them to know too much about each other.
One also often sees a kind of component "registry", where extensions can add new objects that can be used by other code, or new functions that can be called, or where extensions can replace existing components.
However, while the internal API for facilitating interactions between extensions and the core system is often robust and clean, web frameworks generally provide only the most rudimentary higher-level maintenance support for managing extensions.
What exactly do I mean by "higher-level maintenance support for managing extensions"?
If we take a look at software that is one-level higher-up and removed from a web framework, like a Content Management System (CMS) or a blog, what we often see is quite elaborate support system for maintaining extensions.
Such a support system can include an administrative backend that can provide information about current installed extensions and their version and status, and a button to click to check for extension updates online. The online update check can be as full-featured as a desktop update check tool, providing information about new versions available -- the changes and release dates, etc. The system may also support dependency checking between multiple modules, and report on incompatibilities and dependencies between extensions. The administration system may even support searching for extensions online, and then automatically downloading and installing (or uninstalling).
In one aspect, extension updates/installs/uninstalls for online web services are more complicated then desktop applications, and that is when the database needs to be substantially altered. Whether one is installing, updating, or uninstalling, the need to perform database upgrades can be tricky (especially for a live system). Frequently one may want to save a database backup to be able to roll-back a problematic update, and one may need to take the system offline while updating.
I take the position that such functionality is exactly the kind of thing that a framework should do more to assist: It is common functionality found in most modern web applications, represents a substantial amount of coding, is hard to code properly and is hard to maintain. This is especially true for the situations where an extension update needs to perform some one time database updates. In short, this is an areas that a web framework should do much more to assist with -- building a web application should not require the coder to reinvent the wheel when it comes to supporting extensions. And yet it is an area that few (any?) web frameworks support robustly.
The support for such extension management and updating is a good example of how Mewlo is trying to occupy a middle ground between traditional web frameworks and higher level content management systems. In some ways you might say that Mewlo is more of a Content Management System Construction Kit.
mouser:
By the way, for those interested in being part of the project, I'm planning on holding the First Annual Mewlo Conference in Champaign Illinois in May 2014.
mouser:
FYI: I'm just getting back into Mewlo work after a couple of months break.
mouser:
Mewlo Web Framework Blog Entry #5 - January 29, 2014 - Third Party Components
So I took a little time off working on Mewlo, but I'm back to it now, and starting to have a little more fun with it.
Today I thought I'd talk a little bit about which components of Mewlo will be handled (at least initially) by 3rd party open source libraries.
I see Mewlo occupying a middle ground between Django, a framework which uses very few 3rd party components, and Pylons/Pyramid, which is heavily reliant on 3rd party components (both excellent frameworks).
First, let's talk about different ways one might utilize 3rd party components/libraries in a framework.
In the Pylons/Pyramid framework, the framework works hard to make it possible for programmers to use alternative components for major core functions -- such as the database engine, the template engine, etc. The advantages of such an approach is that the coder is free to use whichever alternative components they prefer. The disadvantages are that the framework cannot rely on the existence of features and functions, and must sometimes go to extreme lengths to coordinate actions, resulting in overly-complex code. Sometimes operations must be left to the coder to implement simply because the framework cannot know how the operations would be implemented by different components. Each component has it's own way of working and it's own coding conventions.
Django, in using custom in-house components for most things (database engine, templating system), can offer a more uniform API and a cleaner more integrated framework. Components are highly optimized for the framework and follow a unified set of conventions. The built-in Django components are actually quite excellent. The disadvantages of such an approach include the in-house coding and maintenance effort required for such components, rather than relying on a high quality active third party open source component, and inflexibility of not allowing programmers to choose their own components for core features (database engine, templates, etc.).
With Mewlo, a conscious effort has been made to follow a philosophy of "one right way to do things". As such, we are not concerned with offering programmers the flexibility of using their own database engine, template engine, etc. I realize this can be a controversial decision for some -- and where there is no real complexity cost associated with offering choices (as is the case with template engines), we may relax this strategy. But in general, we begin with the premise that enforcing the use of a specific component set is not a bad thing.
Furthermore, Mewlo leans much more heavily in the direction of reinventing-the-wheel and writing code in-house, for most functionality. As such we avoid the use of components when such components are integrated tightly into the framework -- it's my belief that the more different components maintained by different organizations, the more moving parts there are that lead to messier and convoluted code.
Having said that, Mewlo does use some key 3rd party components/libraries. These components represent a substantial amount of non-trivial intricate code and they are actively developed and maintained by other entities. It is judged that reinventing these components would not be a good expenditure of time, and we have tried to focus on components that do one thing well.
But, it should be noted, that Mewlo makes an attempt to abstract the interface to these components using thin-wrappers, so that all user-written code goes through a Mewlo API, rather than interacting with these 3rd party components directly. This has several benefits. First, it allows Mewlo to present a uniform outwardly-facing API interface. Second, it allows us to replace components in the future without changing the basic API. Third, it's consistent with our strategy of designing Mewlo as an language-neutral OOP hierarchy that we could move to another language.
Note that the 3rd party Components I am speaking of here are python libraries that play essential core roles in Mewlo. I am not talking about occasions when some custom user code will want to use an arbitrary library to perform some limited action.
Template Engine - Jinja2
------------------------
We have preliminarily chosen the Jinja2 templating system for Mewlo (we could have just as easily chosen mako). As discussed earlier -- a programmer using Mewlo does not invoke Jinja2 functions directly, but acts through an abstract Mewlo class that could easily be extended to support additional templating engines.
ORM Database Layer - SqlAlchemy
-------------------------------
For database operations that do not have to run at the absolutely fastest speed, there are huge advantages to using an object-oriented ORM database layer. An ORM database library/component is an intricate thing with lots of moving parts that relies on some esoteric language features. As such, it's exactly the kind of thing that we would prefer to hand off to a well-maintained 3rd party component. SqlAlchemy fits this bill nicely. Again, all database operations are done via Mewlo classes, which abstract the calls to SqlAlchemy and facilitate DRY coding with minimal reuse of configuration information.
Form Construction and Validation - WTForms
------------------------------------------
Mewlo currently uses the small WTForms library to handle form creation, presentation, and validation. Form handling is small enough in scope, that we could replace this in the future with our own custom library -- or move to a larger form library. For now it represents a good solid minimal form handling component.
Low-level Web Objects - Werkzeug
--------------------------------
Mewlo currently uses the Werkzeug library to handle the low level request and response objects (including cookies, etc.) that lie at the heart of a web framework. The choice of Werkzeug does violate one of our guidelines for choosing 3rd party components in that it includes code to provide a large number of features that we have no interest in using. Because we only use minimal pieces of the Werkzeug library, it is highly likely that we will rewrite this component in-house for Mewlo, or move to a much more minimal library for request and response handling.
Others
------
There are several parts of Mewlo that have not been implemented yet, but which will most likely depend on the adoption of 3rd party component libraries:
* Css/Javascript/Ajax frameworks
* Internationalization library
Navigation
[0] Message Index
[*] Previous page
Go to full version