-
Templating system for PostNuke chosen
(News)
-
The decision was reached through the following 6 criteria.
Performance
The chosen system performed considerably better than both the existing theming engine and the Encompass engine. Testing indicated a performance increase of 15% compared to the existing engine and 95% compared to the Encompass templating engine. Further gains due to optimization are likely. Benchmark results are appended at the bottom. Please note that while great care was taken to benchmark all contenders in the best possible way, there is always room for discussion with benchmark results. The results support the verdict with a satisfactory margin of error however.
XML syntax
Having a good XML story is crucial going forward, with XSLT and related technologies replacing HTML longer-term. The chosen engine uses XML Namespaces to prepare PostNuke for a point in time where it will be feasible to turn over some of the rendering duties to the client. Furthermore, XML increases readability and provides less of a learning curve than Smarty's syntax. XML syntax also allows easy development of templates within WYSIWYG HTML editors.
Small codebase
An important consideration in the decision was overall code size. Smaller code has a large maintenance advantage, and thus weighted heavily in the decision. The Blocklayout engine weighs in at 15KB, the Encompass engine weighs 227KB - 400KB, depending on what is counted.
Hierarchial templating
Templating should be hierarchial for maximum expressive power. This allows to compose page layouts from small building blocks. The chosen engine embodies this concept.
Directory structure
Encompass stores all templates in one folder, regardless of type. Blocklayout separates templates by classification.
1) pages/ - Full page skeletons
2) blocks/ - Block templates
3) modules/(modname)/(functype)/(funcname)/ - Module output templates;
there can be multiple, interchangeable templates for the same module
function even within the same theme. If one is not present the module
uses its own internal default.
Integration with Roadmap
PostNuke has been evolving very rapidly over the course of the last year. The future will bring more changes still. It is imperative that the templating system be able to cope with changes. One way to do that is to have a clear plan where the future direction is concerned. Another is to have a team that is in constant communication with the
PostNuke team.
Information on Blocklayout
Templates
There are 3 kinds of templates in Blocklayout, Master, Slave, Internal. Masters define the overall layout of the page. Slaves "dress" each piece of centent in the theme. Internals lay out the actual content.
Template Locations
Modules and Blocks are distributed with an Internal template for each function that deals with output. These templates are used if there is no correspoding template in the theme. Themes are not required to contain Internal templates.
In fact, I suggest that themes don't. Internal templates in themes is intended as a way for each individual site owner to customize their site even more; the ability of theme designers to include Internals in their theme is a bonus. Obviously, it would be impossible for a theme to include templates for every module.
Themes are only required to contain Master and Slave templates. The Master templates remove the limitation of the 5 zone layout PostNuke currently has. Slave templates replace and extend certain functions within theme.php, such as
themesideblock() and OpenTable() / CloseTable().
Having a standard set of CSS classes will ensure that any properly designed module will integrate with any theme, without the need for any theme to contain Internal templates. This also gives PostNuke the ability to be laid out completely with CSS. Other classes can be added by the theme designer. This also reduces reliance on theme variables such as colors.
Blocklayout Specification
http://www.thedragonsforge.com/postnuke/blocklayout_40.html
Benchmark Results
Encompass:
ab -n1000 -c2 site1
This is ApacheBench, Version 1.3c apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software: Apache/1.3.19
Server Hostname: 8.hostnuke.com
Server Port: 80
Document Path: /pn713/index.php
Document Length: 35277 bytes
Concurrency Level: 2
Time taken for tests: 437.928 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 35778000 bytes
HTML transferred: 35277000 bytes
Requests per second: 2.28
Transfer rate: 81.70 kb/s received
Connnection Times (ms)
min avg max
Connect: 0 0 39
Processing: 659 875 1091
Total: 659 875 1130
Blocklayout:
[root@ns5 /root]# ab -n1000 -c2 site2
This is ApacheBench, Version 1.3c apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software: Apache/1.3.19
Server Hostname: 8.hostnuke.com
Server Port: 80
Document Path: /html/index.php
Document Length: 9315 bytes
Concurrency Level: 2
Time taken for tests: 223.446 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 9832256 bytes
HTML transferred: 9321746 bytes
Requests per second: 4.48
Transfer rate: 44.00 kb/s received
Connnection Times (ms)
min avg max
Connect: 0 0 2
Processing: 271 446 656
Total: 271 446 658
Traditional PostNuke:
[root@ns5 /root]# ab -n1000 -c2 site3
This is ApacheBench, Version 1.3c apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software: Apache/1.3.19
Server Hostname: developer.hostnuke.com
Server Port: 80
Document Path: /index.php
Document Length: 12971 bytes
Concurrency Level: 2
Time taken for tests: 260.773 seconds
Complete requests: 1000
Failed requests: 259
(Connect: 0, Length: 259, Exceptions: 0)
Total transferred: 13475259 bytes
HTML transferred: 12971259 bytes
Requests per second: 3.83
Transfer rate: 51.67 kb/s received
Connnection Times (ms)
min avg max
Connect: 0 0 4
Processing: 359 521 758
Total: 359 521 762
Generated on May 28, 2002.
-
Postnuke in the Real World!
(News)
-
Here's what I have observed. Agree or disagree as you wish. Please don't flame me (I'm human too!).
0) There is a level or resentment/hostility within the O/S community towards organisations which are interested in 'commercialising' the purity of O/S.
1) Certain Open Source (O/S) projects are outstanding in the level of commitment and contribution and development from a wide range of parties (amateurs, hobbyists, enthusiasts, commercial interests, community groups etc.). PN is certainly a remarkable 'upgrade' from the closed PHP-Nuke circuit, has suceeded in delivering a teriffic rewrite and code cleanup, great new features and a new version every 12 weeks or so with lots of improvements - it is going places and in the right direction.
2) There is not widespread adoption or support of Open Source products in a corporate/commercial environment. To a substantial extent there is ignorance of the existance of quality software other than through traditional vendors of proprietary solutions. How do you submit a Tender Document or RFP to the Open Source community?
3) The GPL's protection of 'without warranty' is appropriate to enable the development and use of O/S applications [in the public domain] while ensuring that there are no warranties expresssed or implied on the part of the authors. WYSIWYG! This is not an acceptable level of 'support' for a business critical application and is what scares most corporates away from even investigating the O/S route. In reality there is not much better 'protection' afforded by proprietary vendors/licenses but they are used to those and do not look as deeply as they should. At the end of the day they think, regardless of the legal protection of a license, "I paid the guy to do X, he didn't, get him in and whip his ass". As a paying consumer you have independent rights to protect your investment - the absense of contract or payment means you take what you get and shut up if you are not happy.
4) Because it is 'public' and 'open to anybody' to adopt/present Open Source solutions and because the 'barriers to entry' are so low (free) - anybody can set up shop and 'sell' O/S products and support. This is fine, but the lack of viable commercial model (i.e. revenue stream) on the part of many sole-traders/consultants is not reassuring the commercial world as to the practicality of considering O/S - this is the so-called 'Geek Factor'. The 'Geek Factor' is the most difficult marketing message for commercial proponents of O/S to counteract. Wear a wolly jumper, work from home, grow a beard, write O/S, sell mugs and caps on your website so that you can buy pizza and beer. Suits like to deal with other suits, in person, eye-to-eye.
5) No large corporate would consider adopting an Open Source product unless (a) there was a team [not an individual] of developers/support people in house with the skills OR (b) there was an external software house with the skills and a team [not an individual].
6) Free software is only value for money in the up-front licensing sense. The "cost of ownership" models (service, maintenance, adaptation) which apply to proprietary software still are the same if a corporation is adopting an Open Source product to use.
What we (proponents of O/S philosophy) need to make clear is that ...
=================
1) We are going to make money selling and supporting this. If we don't make money we won't be in business for long and the support will cease. Problem. The profit motive is a compelling case.
2) We have a team of developers/support personnel. The one-man-band is not viable for 'critical' applications. Most corporates regard the website as critical and also any services which are web-based. You have to be able to provide a credible SLA (service level agreement) and have the capacity and depth to meet the commitments.
3) There is no "Mickey Mouse" pass-off of responsibility (as defined in the GPL). In the GPL you take the software 'without warranty' etc.. A business will need better than that if it is to depend on the applications. This is the most essential clause in the GPL (to protect an author from any form of liability or responsibility). I know that most 'proprietary' product License Agreements actually make the same pass-off of liability/responsibility but they are not as blatant and people/organisations feel that there is some leverage with a vendor who is getting paid for software to ensure that it meets the documented functionality.
4) They are going either (a) to save money or (b) get better systems/service i.e. value by going down the proposed O/S route. The initial 'savings' are only valid if the total cost of ownership (TCO) shows savings.
5) No medium-large company will want to adopt a system if it contains a single critical point of failure. While the co-operative model may be 'nice' it breaks down if I can't sue a vendor of substance if they mess up. This is why it is difficult, even with small companies, to be successful at outsourcing software development or support if you are a 1-man-band. The exception is where there are clearly defined projects which can be outsourced and where there is the in-house team to take over at completion/delivery.
6) There are other benefits to O/S software which are somewhat more intangible but of value - especially the availability of the source code so that the traditional 'golden handcuffs' syndrome with proprietary vendors is not a factor.
Conclusion:
What is really boils down to, I believe, is that the real assessment of whether a solution is a GOOD SOLUTION is more dependant on the party proposing than the software itself. I (personally) sold accounting systems for years with lots of happy clients. Other resellers of the same product had lots of unhappy clients. Same product, different service, different customer experience.
My favourite line.. "Good, quick and cheap; which 2 do you want?". Quality, Responsivness and Cost are intrinsically linked in the real world.
Here's what we (Experience IT) would like to achieve:-
===============
1) To be able to tap into the expertise in the general community with parties who do not wish to have 'customers' only projects that pay fairly from time to time.
2) Be able to call on some of the core development team (email or otherwise) for that special level of support (from time to time) as might be required (and pay for the service).
3) Be able to work with specialists in areas (e.g. theme designers/graphics artists) who would be prepared to accept a brief and agree a fair price for the work.
4) Have a means to 'give-back' either through donation, revenue share, code share, hosting or other tangible form of support to the community which created such wonderful products.
Generated on February 14, 2002.
-
Corporate use of PostNuke...
(News)
-
Proxy settings: One place to configure proxy server settings is needed. config.php is the obvious contender, but there needs to be a define in each module (if needed) to turn proxy use on or off.
The changes to the user system seem to be going in the right direction. I'd like the ability to treat 'anonymous' as a user in order to provide controlled access to articles/files/modules depending on a user's status. In other words specific articles/files/modules should be flagged as readable/useable by anonymous users.
The ability to have unmoderated posts by authenticated users.
A lightweight blogger system per user. To keep a personal journal, viewable by none(i.e. private)/authenticated/anonymous depending on config.
I'm in the early stages of looking at modularising the Meeting Room Bookings System. As I'm pretty new to PHP don't expect speedy results. Once I have something working I'll publish a pointer to it. I'm really waiting for a stable 0.64 release before I get too deeply involved.
LDAP authentication is going to be increasingly important for us. Active Directory will be arriving fairly soon, I'd dearly love to query the LDAP database and create users in bulk
Just my ha'penny worth.. cheers.
Generated on October 4, 2001.