Aimless rants on sustainability, food-sovereignty, and the cyber-revolution.
Showing posts with label Drupal. Show all posts
Showing posts with label Drupal. Show all posts
Friday, May 22, 2009
Sunday, April 20, 2008
On the Framework Merry-Go-Round
So I have been actively working with drupal for the past several months, trying to get it up and running for an NGO in India. The experience has been fairly smooth and I have even gotten the hang of developing and extending modules for the system. Just a couple of weeks ago following some self-assessment on working with drupal I began considering it as framework for developing a pattern based knowledge management system.
That was of course until two interesting conversations took place. The first conversation was with Yishay who pointed me to the Google Appengine project. He already knew I was a fan of python and django so he brought this up as an alternative to working with drupal.
In all honesty (as I have said in previous posts) I would rather develop with a language like python and framework such as django. Now with the added integration with Appengine it seemed as a an interesting direction to take.
Strangely, the next day at work I was given the green light to begin diving head first into this django/appengine phenomena. We have been actively using SharePoint for most of our projects. Whereas myself I have bucked the system from the get go, instead opting to use google apps and/or building my own as needed.
Well, it seems that my efforts did not go unrecognized and with the help of a few collegues it seems that the google route was partially embraced even if it was just from the standpoint of conducting an investigation of what we might be able to do.
Personally, I would love to develop solely with django and python at work, and well it looks like I get my wish. So for this summer I get to spend all of my time getting acquainted with appengine and see what it can do. Where does this leave me with drupal and my knowledge management system? Well, it leaves with wrapping up my current project for JESA and most likely focusing on using the django framework as the foundation for developing the components needed for my system.
I feel like I have been on a merry-go-round, but considering the options, this summer's work and fellow colleagues giving me the space to become relatively proficient with this system it seems like a given that I will try and use this framework to produce my software.
I'm actually pretty excited about the prospect, as it seems like I'm in a perfect position to take advantage of the django/appengine integration. I'm a huge python fan and it is the language I'm most proficient with. I know django, having built a couple of blog and wiki apps (one day I will move this blog to the one I built), and well appengine uses BigTable and that looks to be an interesting adventure. So taking that together with what I want to do with the application I'm building it seems like a great tool set.
So, thanks Yishay, thanks Gary and definitely thanks to Jamie and Theron for pushing a multi-paradigm software shop at CTLT.
That was of course until two interesting conversations took place. The first conversation was with Yishay who pointed me to the Google Appengine project. He already knew I was a fan of python and django so he brought this up as an alternative to working with drupal.
In all honesty (as I have said in previous posts) I would rather develop with a language like python and framework such as django. Now with the added integration with Appengine it seemed as a an interesting direction to take.
Strangely, the next day at work I was given the green light to begin diving head first into this django/appengine phenomena. We have been actively using SharePoint for most of our projects. Whereas myself I have bucked the system from the get go, instead opting to use google apps and/or building my own as needed.
Well, it seems that my efforts did not go unrecognized and with the help of a few collegues it seems that the google route was partially embraced even if it was just from the standpoint of conducting an investigation of what we might be able to do.
Personally, I would love to develop solely with django and python at work, and well it looks like I get my wish. So for this summer I get to spend all of my time getting acquainted with appengine and see what it can do. Where does this leave me with drupal and my knowledge management system? Well, it leaves with wrapping up my current project for JESA and most likely focusing on using the django framework as the foundation for developing the components needed for my system.
I feel like I have been on a merry-go-round, but considering the options, this summer's work and fellow colleagues giving me the space to become relatively proficient with this system it seems like a given that I will try and use this framework to produce my software.
I'm actually pretty excited about the prospect, as it seems like I'm in a perfect position to take advantage of the django/appengine integration. I'm a huge python fan and it is the language I'm most proficient with. I know django, having built a couple of blog and wiki apps (one day I will move this blog to the one I built), and well appengine uses BigTable and that looks to be an interesting adventure. So taking that together with what I want to do with the application I'm building it seems like a great tool set.
So, thanks Yishay, thanks Gary and definitely thanks to Jamie and Theron for pushing a multi-paradigm software shop at CTLT.
Labels:
CTLT,
Django,
Drupal,
Google Appengine,
SharePoint,
Yishay Mor
Friday, April 4, 2008
Drupal Module versus Standalone App
Ok, I have found some interesting resources within the Drupal community regarding SVG. In fact, there what appears to be a full feature SVG API for Drupal. Now, even though I'm working with Drupal to develop my prototype app for community natural resource management, I'm wondering if I should adopt the SVG API, or write a standalone app and create a list of functions so the app can interface with Drupal.
I think for the sake of ease it would be better to go the Drupal route, but thinking long-term, I want the app to work in any environment that supports PHP. Surely, I could build the Drupal module first and then begin to think about extending the app, but I'm one of those coders that HATES to repeat my work.
Anyway, if anyone has any thoughts on this it would be great.
If you are new to my blog check out this post to get an idea of what I'm doing with SVG: Need to build some software..., and The process of visualizing complex environments.
I think for the sake of ease it would be better to go the Drupal route, but thinking long-term, I want the app to work in any environment that supports PHP. Surely, I could build the Drupal module first and then begin to think about extending the app, but I'm one of those coders that HATES to repeat my work.
Anyway, if anyone has any thoughts on this it would be great.
If you are new to my blog check out this post to get an idea of what I'm doing with SVG: Need to build some software..., and The process of visualizing complex environments.
Tuesday, November 20, 2007
Transition back to Drupal
So I had written a previous post about my desire not to use Drupal and more specifically PHP for my research project. However, I have done some further in-depth analysis of the requirements for the proposed project and I think that considering the needs for a full featured system along with the ability to extend the system to meet some very specific needs, Drupal presents the best option. Like I said previously, it is cheap to host, the coding quality is much better than comparable PHP based systems and I actually do like the templating system they have developed.
Plus, I think Django will just be too much work to build and get up to speed for this project, and Plone is too expensive to host for the groups I’m working with.
I mean, it is a no-brainer. I don’t despise PHP as a language. It’s more that I prefer Python. In that sense I’m not a complete Python Nazi as some out there are.
In all honesty, PHP 5 is actually a pretty good language, it is easy and when compared to Python, PHP is definitely a much better language for the web, so why not use it? Plus, PHP and Flex work well together which provides greater opportunities for integration with the types of systems I’m focused on developing.
Plus, I think Django will just be too much work to build and get up to speed for this project, and Plone is too expensive to host for the groups I’m working with.
I mean, it is a no-brainer. I don’t despise PHP as a language. It’s more that I prefer Python. In that sense I’m not a complete Python Nazi as some out there are.
In all honesty, PHP 5 is actually a pretty good language, it is easy and when compared to Python, PHP is definitely a much better language for the web, so why not use it? Plus, PHP and Flex work well together which provides greater opportunities for integration with the types of systems I’m focused on developing.
Thursday, November 8, 2007
Tech Stack for CI (Revised)
In doing further research on available technology options for the visual learning in time and space application at CTLT, I have been considering a move away from Python and Django. Though I love the ease of working with these tools, I'm very interested in using flex to provide the UI and display of learning data.
So it seems that Flex provides an open SDK for PHP developers and not Python. Though a django developer has submitted a bridge for working with Flex, it still seems immature and I need to learn this fast rather than fighting with a system still in development.
With that said, I'm thinking PHP5 + Propel ORM + Flex, and since I will be using PHP I can't help but write a bridge to Drupal. Of course the application will need to integrate nicely with SharePoint as this is going to be the primary test case for using this custom app. However, I'm not using .NET and I'm not willing to write a custom web-part for this as the application must be available to CMS apps outside of the SharePoint MS paradigm.
So it will live as a standalone application in which others can build modules to extend and integrate into their own learning platforms. Plus, this way the application can be utilized for linking into the L.V. Patterns.
So it seems that Flex provides an open SDK for PHP developers and not Python. Though a django developer has submitted a bridge for working with Flex, it still seems immature and I need to learn this fast rather than fighting with a system still in development.
With that said, I'm thinking PHP5 + Propel ORM + Flex, and since I will be using PHP I can't help but write a bridge to Drupal. Of course the application will need to integrate nicely with SharePoint as this is going to be the primary test case for using this custom app. However, I'm not using .NET and I'm not willing to write a custom web-part for this as the application must be available to CMS apps outside of the SharePoint MS paradigm.
So it will live as a standalone application in which others can build modules to extend and integrate into their own learning platforms. Plus, this way the application can be utilized for linking into the L.V. Patterns.
Labels:
CTLT,
Drupal,
Flex,
Liberating Voices,
PHP,
SharePoint
Sunday, November 4, 2007
Evaluating Technologies for CI Research Project
As you might all know I'm particularly fascinated with 3 core open source projects at the moment. These of course being Plone, Drupal and Django. Plone and Drupal are interesting CMS applications which attempt to be usable systems for developing much more complex and customized software solutions. On the other hand, Django is a rapid development framework that could allow for the development of a Plone or Drupal type application. I think all have a very useful place, particularly within the non-profit software development field.
I have issues with each though and in some sense these issues might be ridiculous, but they are my reasons and I have never been accused of being practical.
The first issue though is practical and that is the hosting cost associated with Plone. Though Plone might be the most feature rich platform (not to mention I know it the best), with its stable integration of GIS through the web apps, it is cost prohibitive for most of the groups I'm currently working with. This is very annoying, but that is life.
The issue I have with Drupal is its use of PHP and its non-object oriented approach to using PHP. Yes, for some this is a stupid reason not to adopt a particular solution. After all, I predominately work with PHP. Not to mention, Drupal is full featured and growing rapidly as more users adopt and build custom modules, extending its capabilities. It is also a cheap solution.
Yet, I like Python, its cleanliness, readability and development speed. As a result, Django provides a very enticing opportunity, to build robust apps with Python. Django is also cheap to host. However, despite the useful helpers such as the Django admin, nice permission system and so on, it lacks a lot of the components already available to Drupal and Plone developers. This means that I would have to implement the various components myself or find like minded people interested in collaborating to reduce development time.
Yet, despite this very obvious problem, I find the lack of a django based application to fit my needs to be very irritating as this is perhaps the most powerful Python web framework I have come across (save for Pylons, but crappy documentation makes for crappy adoption). This almost seems to be a calling of sorts. There needs to be a powerful django app similar to drupal for us pythonistas. Yes, there is PyLucid, but the documentation is not very good and the level of deviation from the core django framework just seems unnecessary to me. There is already so much Django offers that it just seems to be a waste of time.
Now, I haven't completely sold myself on using Django, but I'm using it to write a custom shell of a CMS for JESA, currently the site I built is just static HTML, but as the requirements for this site expand dramatically (as I thought they would) they are in desperate need of an easy to use web app that allows them to extend the site and add content with ease.
This is all volunteer work, but there are some things to be said about doing volunteer work versus contract work. I have been given free reign to build the site and to use whatever technology I want provided the site is secure, easy to use, etc.
So a great opportunity to use django. I think after this I will be better able to gauge whether I want to invest the time to build a base CMS for my research or if Drupal will just have to cut it. We'll see.
I have issues with each though and in some sense these issues might be ridiculous, but they are my reasons and I have never been accused of being practical.
The first issue though is practical and that is the hosting cost associated with Plone. Though Plone might be the most feature rich platform (not to mention I know it the best), with its stable integration of GIS through the web apps, it is cost prohibitive for most of the groups I'm currently working with. This is very annoying, but that is life.
The issue I have with Drupal is its use of PHP and its non-object oriented approach to using PHP. Yes, for some this is a stupid reason not to adopt a particular solution. After all, I predominately work with PHP. Not to mention, Drupal is full featured and growing rapidly as more users adopt and build custom modules, extending its capabilities. It is also a cheap solution.
Yet, I like Python, its cleanliness, readability and development speed. As a result, Django provides a very enticing opportunity, to build robust apps with Python. Django is also cheap to host. However, despite the useful helpers such as the Django admin, nice permission system and so on, it lacks a lot of the components already available to Drupal and Plone developers. This means that I would have to implement the various components myself or find like minded people interested in collaborating to reduce development time.
Yet, despite this very obvious problem, I find the lack of a django based application to fit my needs to be very irritating as this is perhaps the most powerful Python web framework I have come across (save for Pylons, but crappy documentation makes for crappy adoption). This almost seems to be a calling of sorts. There needs to be a powerful django app similar to drupal for us pythonistas. Yes, there is PyLucid, but the documentation is not very good and the level of deviation from the core django framework just seems unnecessary to me. There is already so much Django offers that it just seems to be a waste of time.
Now, I haven't completely sold myself on using Django, but I'm using it to write a custom shell of a CMS for JESA, currently the site I built is just static HTML, but as the requirements for this site expand dramatically (as I thought they would) they are in desperate need of an easy to use web app that allows them to extend the site and add content with ease.
This is all volunteer work, but there are some things to be said about doing volunteer work versus contract work. I have been given free reign to build the site and to use whatever technology I want provided the site is secure, easy to use, etc.
So a great opportunity to use django. I think after this I will be better able to gauge whether I want to invest the time to build a base CMS for my research or if Drupal will just have to cut it. We'll see.
Labels:
Community Information Systems,
Django,
Drupal,
Plone
Sunday, October 14, 2007
Another CMS (Django Style)
Yes, I have been playing pretty extensively with Django these past few days and I love it. It is so intuitive for me. I don't think I have found a single approach to web app development that seems as easy as this.
Today, I was working with the default Admin provided and started thinking of ways to alter it and extend it. With Django, they give you the basic things needed, but no more no less. However, many of the pieces given appear to be easily altered and this could prove useful.
See, out of all the CMS apps out there, I like Plone the best. However, the hosting cost can be prohibitive for some groups, also I still don't like the way Skins are developed. I can do it, but for others it seems a bit steep. I'm interested in applications that are fairly easy to extend and customize. In this area Drupal seems to have it right on. However, with Drupal, the Admin is poorly developed and the way in which users interact with content is weird. I also, dislike the lack of structure. The Plone notion of organizing content in Folders just seems super easy versus Drupal's whatever, wherever approach.
Django, as a base framework provides a very simple templating system similar to Drupal, but Django is written in Python, object oriented and all (Yes, I know PHP is OO, but Drupal takes a more procedural approach). Django's admin is also clean and fairly intuitive; it does have some work, but I think I can integrate the Django admin in a more folderish and content/location specific way such as Plone does then we might have a really interesting extension of Django and skeletal app similar to Plone, but with the hosting cost more in line with Drupal.
For me writing an app in Django is much easier than writing a Product in Plone and yet, they function in the same way.
Django issues (these are things that need to get done to make Django more friendly for CMS development):
1. Easily defined URLs, power-users shouldn't have to write regular expressions. When installing an app a site manager should be able to easily set the urls associated with a particular piece of content with out getting into the code. This means users could also add pieces.
2. Users and Group Permissions, Plone does this very well and while Django has a powerful security system is seems pretty bare.
3. Folderish structure. When adding a module or app the piece should act as a folder and the pieces of content associated should be connected to it. For instance, I add a blog module; a base url is generated and anytime I add a blog content-type (e.g. a Post) then that content would live under the blog heading as a child of the blog. This way we could enforce a bit of structure. Of course some people might hate this, but for us Info Architects this structure would be nice.
4. Admin to be embedded. Currently the admin is a whole different piece of the site. The admin should only come up for adding content modules at the root of the site. Below the root, I would think that the admin should be referenced and any edits would be on the piece of content a user is currently viewing. This is also very well done in Plone.
5. In my module app I need to write a piece of code that will allow me to update the urlpatterns(). Unfortunately, the urlpatterns variable is a damn tuple. A list would make life a bit easier.
Anyway, these are some of the things I'm thinking of addressing. If I can work with some haste I might be able to have the first cut before the next semester and maybe we can deploy for the new JESA site. I think I will deploy for my own site first though. Need to watch out for those XSS attacks. I'd rather my stuff crash than theirs.
Today, I was working with the default Admin provided and started thinking of ways to alter it and extend it. With Django, they give you the basic things needed, but no more no less. However, many of the pieces given appear to be easily altered and this could prove useful.
See, out of all the CMS apps out there, I like Plone the best. However, the hosting cost can be prohibitive for some groups, also I still don't like the way Skins are developed. I can do it, but for others it seems a bit steep. I'm interested in applications that are fairly easy to extend and customize. In this area Drupal seems to have it right on. However, with Drupal, the Admin is poorly developed and the way in which users interact with content is weird. I also, dislike the lack of structure. The Plone notion of organizing content in Folders just seems super easy versus Drupal's whatever, wherever approach.
Django, as a base framework provides a very simple templating system similar to Drupal, but Django is written in Python, object oriented and all (Yes, I know PHP is OO, but Drupal takes a more procedural approach). Django's admin is also clean and fairly intuitive; it does have some work, but I think I can integrate the Django admin in a more folderish and content/location specific way such as Plone does then we might have a really interesting extension of Django and skeletal app similar to Plone, but with the hosting cost more in line with Drupal.
For me writing an app in Django is much easier than writing a Product in Plone and yet, they function in the same way.
Django issues (these are things that need to get done to make Django more friendly for CMS development):
1. Easily defined URLs, power-users shouldn't have to write regular expressions. When installing an app a site manager should be able to easily set the urls associated with a particular piece of content with out getting into the code. This means users could also add pieces.
2. Users and Group Permissions, Plone does this very well and while Django has a powerful security system is seems pretty bare.
3. Folderish structure. When adding a module or app the piece should act as a folder and the pieces of content associated should be connected to it. For instance, I add a blog module; a base url is generated and anytime I add a blog content-type (e.g. a Post) then that content would live under the blog heading as a child of the blog. This way we could enforce a bit of structure. Of course some people might hate this, but for us Info Architects this structure would be nice.
4. Admin to be embedded. Currently the admin is a whole different piece of the site. The admin should only come up for adding content modules at the root of the site. Below the root, I would think that the admin should be referenced and any edits would be on the piece of content a user is currently viewing. This is also very well done in Plone.
5. In my module app I need to write a piece of code that will allow me to update the urlpatterns(). Unfortunately, the urlpatterns variable is a damn tuple. A list would make life a bit easier.
Anyway, these are some of the things I'm thinking of addressing. If I can work with some haste I might be able to have the first cut before the next semester and maybe we can deploy for the new JESA site. I think I will deploy for my own site first though. Need to watch out for those XSS attacks. I'd rather my stuff crash than theirs.
Wednesday, October 3, 2007
Back into the world of Plone
So in my current job much of my focus is in designing, developing and using MS Sharepoint as a collaborative knowledge management/community workspace and e-Learning platform. I do however have some issues with this. Not that this is a bad technology, but there are some annoyances and my own leanings are towards open source solutions as apposed to the MS model and their goals to take over the world through vendor lock-in.
However, in considering the role of the L.V. patterns as ways to design effective, life-affirming community applications I'm constantly being brought out of the Sharepoint paradigm and back into the world of open source by way of Plone and Drupal, two awesome projects that never cease to amaze me.
Having worked with Plone for almost 2 years now as a content creator, site manager, and eventually as designer and component developer, I find myself asking questions about the usage of patterns and pattern languages for effective community information systems in terms of harnessing Plone (or Drupal depending on the user reqs.). For one it is open source and most community groups don't have the funds to dish out the money for Sharepoint technologies, nor the funds necessary to run these systems once the licenses are purchased.
Understanding these limitations I think of Plone and Drupal as being more realistic test-beds for extending the CMS and community information systems ideal through use of L.V. patterns.
So as fate would have it I had a conversation with Yishay in London about the idea of developing modules for Plone and Drupal for a project we are putting together. He was in total agreement with the idea. In fact, it looks as if we can dove-tail nicely as he intends to focus on Drupal and I will work with Plone in order to ensure that we can meet as many users as possible through our work.
So as one would guess, I have been cracking away trying to get acquainted with the new Plone 3.0.1 release, and I must say, I am impressed! Great changes, fast user-friendly. I mean it is still difficult in some aspects but from the standpoint of building and deploying systems for people with minimal technical skills, the new Plone version appears to be a hit.
With that in mind I'm going to do my best to stay focused in further developing using this platform. By focusing on extending these two applications it’s my hope to 1.) Not re-invent the wheel (like many programmers, I'm lazy), 2.) Can use the proven successes of these technologies, and 3.) We can provide useful tools to an already large user base.
However, in considering the role of the L.V. patterns as ways to design effective, life-affirming community applications I'm constantly being brought out of the Sharepoint paradigm and back into the world of open source by way of Plone and Drupal, two awesome projects that never cease to amaze me.
Having worked with Plone for almost 2 years now as a content creator, site manager, and eventually as designer and component developer, I find myself asking questions about the usage of patterns and pattern languages for effective community information systems in terms of harnessing Plone (or Drupal depending on the user reqs.). For one it is open source and most community groups don't have the funds to dish out the money for Sharepoint technologies, nor the funds necessary to run these systems once the licenses are purchased.
Understanding these limitations I think of Plone and Drupal as being more realistic test-beds for extending the CMS and community information systems ideal through use of L.V. patterns.
So as fate would have it I had a conversation with Yishay in London about the idea of developing modules for Plone and Drupal for a project we are putting together. He was in total agreement with the idea. In fact, it looks as if we can dove-tail nicely as he intends to focus on Drupal and I will work with Plone in order to ensure that we can meet as many users as possible through our work.
So as one would guess, I have been cracking away trying to get acquainted with the new Plone 3.0.1 release, and I must say, I am impressed! Great changes, fast user-friendly. I mean it is still difficult in some aspects but from the standpoint of building and deploying systems for people with minimal technical skills, the new Plone version appears to be a hit.
With that in mind I'm going to do my best to stay focused in further developing using this platform. By focusing on extending these two applications it’s my hope to 1.) Not re-invent the wheel (like many programmers, I'm lazy), 2.) Can use the proven successes of these technologies, and 3.) We can provide useful tools to an already large user base.
Subscribe to:
Posts (Atom)