What?This is a simple CMS, and document framework. It is built inside the ideas of NoSQL and big data, but is a simple page renderer. The actual goal of the hosted project is self publicity and tech blog.
Iceline is a piece of software to be run on a webserver to build web resources. The libraries are capable of being run outside of the webhost, but would need reconfiguring.
It is a framework to allow management of HTTP headers, access structures, meta information, page templates, content human language selection, MVC structures, separation of content and presentation. It is to do as much of the mundane administration as is possible to allow designers to create websites/ web applications.
Over the long term, pages like this are what I would like this platform to allow you to easily and cheaply build. Most of this can also be achieved via wordpress or drupal etc. As a comparison, I was asked review viyali in Nov 2013, I hope to differentiate myself..
This is a process, not a product. I am creating things, testing them, deploying them; then repeating, destroying the previous structures if necessary; to add a few extra features. My goal is on this process have an expanding structure, rather than published assets. This process is common amongst webservices, but leads to code you don't present as glamorous code.
Please read :
- My spiral of development
- Docs for v1 resource format
- Docs for v2 resource format
- Notes for config file
I will hopefully be in position to abandon PHP 5.1 and PHP 5.2 as supported platforms before first quarter 2014. This means I can support current classloaders, PSR-01 and namespaces. When this happens I will move things around about, so code may be linked into Zend or Symfony without effort. I will add alot of interfaces, to allow a broader range of technology implementations.
- Why write this?
- Initially, I needed more PHP5 experience, and visible experience is more useful than hidden back office works;
- The site, to make my detail-centric CV smaller and lighter;
- To supercede and eliminate earlier code bases %;
- Okay, this is several years later, why now?
- Mostly as professional development. I am a stronger software engineer than a web designer;
- To allow a backstop against whatever poor engineering platform that other people are currently using;
- I would like to have a good platform to use in future;
- Surely it would be better to contrib to a larger project?
- I want to play with a few ideas;
- This is a tool in its own right;
- Over the larger scale, you are correct; but this is a thing I can put my name to, rather than a series of patches;
- I will also contrib to frameworks;
- Why is there no JS in the framework?
- To be more platform agnostic, one may add any JS frameworks one likes;
- You only support full HTML pages?
- Not true, please see examples;
- Why is this platform better than just a PHP interpreter ?
- There is a lot of effort put in, so what the site creator does is much simpler.
- This adds a lot of domain specific features.
% Thinking about this; this project, on completion encapsulates five earlier projects. I imported no source, but took the design and methods. I wish this to be the last one, it is the least rushed.
Why is it built like this?
- Mostly because my second goal practising Agile structures;
- This is hard for me, and so good practice;
- As soon as I setup a PM software my activities will be clearer. I have a set of goals, and am doing iterative development;
- In the last quarter of 2013, I will be adding new technology, rather than supporting widely used standards;
- Many of the core v1 features where built as a site in a 5wd sprint. This was to free my attention for writing, which is more important;
- To view the code as a quality artefact, separate to the building process, is unreasonable for the early builds. I am not selling software. The later builds will have all the person-hours work necessary for a product;
- The quality of the design is improving, as I get frustrated with lack of scalability, or poor support for tools (I entirely deny a learning curve, but deployment of increasingly thorough artefacts);
- I will start using tags and real release numbers when there is more base work done, so everything is structured. I am publishing early and fast, on the basis I may get outside opinion;
- Please wait for a complete toolset;
- Why do I write in lists all the time?
- To attempt to prune unneeded words;
If you read iceline source code, you may see functions named something like XXX_something. These are all executable placeholders, and will be eliminated from later builds. This lets me quickly add new features, but entirely acknowledge the requirement for more work.
Why would I (the reader) use this?
- The more mature projects (such as wordpress) don't fit your requirements.
- This project represents hundreds of hours of work, which you won't need to apply to anything you do your self.
- You are a designer ~ not an architect ~ and core structures aren't your strength.
Computers have traditionally been poor at supporting the full range of human languages. Until recently to have good computer support for your language you needed to have strong international trade agreements, integration with the international banking and a strong international presence. At this point you are probably fluent in en_US to talk with US business people, and so could use an en_US linguistic system.
Over the last six years my local systems are now support Unicode properly. That is anything I do may be in Unicode, and it will work. I do like being able to copy and paste any human language correctly, I read wider than I may type on a en_UK 101 keyboard. I am aware that other systems did this earlier, I have been using Unicode supporting systems since 1999, like Java. Personally, unless your log files support it, and all the other “not headline” tools, I would favour the older standard.
Older versions of HTML supported characters outside of ASCII127 by HTML entities. That is a multi-byte text encoded symbol, rather than native multi-byte symbols. The additional range of items was weak on typographic glyphs which I am now able to add into my content to support proper typesetting.
However, I wrote this section as a justification for adding all the data sections that duplicate information in a non-constrained fashion. There is support in the standards for allowing Unicode in domain names, in URIs, and certainly as HTTP GET or POST name and values. However it is support for, not native use; it is normally horribly clumsy. On this basis I favour simple and reliable naming schemes on the more computer centric sections of the platform like URLs, this is my leveraged solution. As this is a GUI, all the buttons may be in a language of your choice. The additional data items allow editing from the convenience of your normal editing tools.
A more thorough article on this in PHP is written 1. All of the resources and testdata shipped with the code bundle are in Unicode/ UTF-8.
On completion, iceline should:
Please note, the processor for the dynamic functions defined inside the resources them-selves will capture all the PHP warnings that are in the resource. Please write clean code.
- Support static and dynamic web resources;
- Support common internet formats (limited to open source ones, no expense should be necessary to run this);
- Be standards compliant/ encourage standards ;
- Be supportive and friendly with small devices/ mobiles;
- Provide mechanisms for creating applications ;
- Provide “widgets”, so applications are a few lines of configuration & the branding CSS to style it;
- Provide multi-lingual mechanisms (so there can be a version for each locale your site is published to);
- Support user identification and session tracking;
- Support access permissions and restrictions;
- Support partial documents (for AJAX/ AJAJ);
- Support caching of each computed step;
- Be runnable on any webserver that supports htaccess & PHP;
- Make creating attractive forms easy;
- Support shopcart type features;
- Support finance/payment systems, as far as this doesn't conflict goals;
What iceline is not likely to do
- Be visible, in the result sites;
- Provide lots of JS (jQuery is a better, more supported library). I like JS, I use it judiciously, but it is specific to each application, so not a library;
- Provide hosting plans;
- Be a “single click site builder”, this is reduction in administration; I abhor tools that limit artistic freedom;
- Be hosted inside another coding language (I don't see the benefit in rewriting everything, PHP is widely used, and installed);
- Tell you what to do, in terms of DB, or similar extras;
Usecase for this CMS
- The most important one is to be able to publish static technical content, similar to CPAN. This is separate to the ob website, which is the current content.
- As the features of format2 stabilise, to be able to build dynamic websites.
- To be able to build subpage sites (i.e. use AJAX).
- Future builds will be able to create template emails.
Comparison to other platforms
At present this is under development. I recommend the use of more mature platforms.
At full features, in the future; the goals of “open source” mean I still recommend the larger projects, as they have better community. In terms of glamour, this is a shame; but wealth of the commons is a better basis for development. The community is stronger than an individual.
As I am implementing the rest of my ideas, the features comparison between the different systems becomes more blurry. But to repeat earlier lines, this is a developers tool, not a thing to make designers unemployed.
In theory my design is better at security, but until it has complete features, and it is given the same use as Drupal or wordpress; this statement is a promise.
The iceline source is hosted on SF
If you need to mark a site down for maintenance, create a file called 'notice.html' in the doc root. The software will render this as a page rather than whatever the server is setup for. Future builds may allow more of a framework, so you don't need to set the whole document.
Project directory tree
If you view this as a source bundle rather than a website you may see the following ::
ast .. .. external .. .. index.php lib: 00RendererInterface.php 01HTTPObject.php 02PageResource.php 03HTTPEater.php 04IOInterface.php BadConfigException.php BadFilesystemException.php BadImplException.php BadPageHandlerException.php BadResourceException.php BadSessionException.php BadVersionException.php Config.php EmptySession.php ExternalRedirectException.php FallBackException.php HTMLise.php IllegalRequestException.php IO: SMTPimpl.php TwitterImpl.php IOAccess.php IOlayer.php Log.php NewPageException.php NoCodeException.php renderer 01minimal_html4.php 03combined_html4.php resource BinaryResource.php MultiResource.php WikiResource.php ResourceWriter.php Session.php TypeConvertException.php UnknownDataTypeException.php ValidationFilter.php live.htaccess log render.php res .. .. robots.txt test .. .. tiny-url.php
Included in the source is a all-get resource to attempt to run all the do_get functions, to make spotting errors in designer resources more transparent. A similar do_post isn't practical, as the single resource can't invent all the necessary POST param.
There is a mirror resource, for application testing, to make it easy to see what parameters are getting into a resource.
If you are running on “my test machine” the logging writes everything to disk. Otherwise the logging is discarded to avoid disk saturation. “my test machine” is defined in the config file, if you search for MY_TEST_MACHINE, and change the listed IPs to whatever your local interface is. The internal hyperlinks will work correctly if you set “site_baseurl” to whatever your machine is using...
At present, there are test data to cover nearly all of the inputs to iceline as a piece of software. This allows the majority of the code to be executed ahead installation anywhere, and so all the obvious errors detected. There aren't really unit tests against the individual classes, due to the code being quite simple, and the difficulty in reducing dependences to demo each class. Each test case would require the creation of a large amount of code. As the amount of decision-making increases, I will build unit tests in normal fashion. I think they will be necessary as a precursor for the proper data channels (scheduled for v2.5). I need to build a complete set of tests for multi-language support, that is any of the internal string manipulation is stable for multi-byte.
There is test data in the directory 'test' in the source bundle. Please do not add the test resources (named 'sample-*') to live websites.
This functional test data covers both file formats for v1.X and v2. These will be ported to sensible framework before version 2.3. The majority of the possible options ~ by design ~ are stored in the page resource.
In future I will add “example resources” which are resources demonstrating and documenting features of the platform. They will be named 'test-*', and be access group 4. This is to allow other less technical designers create sites within this platform.
I have created the following test data, I need to make many more before the software is complete.
- runner-066-viewsource * tends to segfault
- runner-077-docversion-2 -- oops, naming wrong
- runner-108-viewsource * tends to segfault
- runner-114-tagCloud %
- runner-116-jobSites %
- runner-140-include-6 ~ accidentally double numbered, so had to move this one up.
- runner-154-qunit %
- runner-159-browser-capture %
- runner-177-sitemap.01 %
- runner-178-browser-capture %
Items marked with a '%' are test entries for a specific resource, as I was having problems configuring it. These probably shouldn't be included in the published source, if the resource isn't included in the source distributed. I will add some verification tools in future, so every resource is rendered in one hit.
The segfault occurs on large files being included in the source viewer. It doesn't occur on small files. It doesn't occur in the same large file rendered directly.
Will be resolved... Think this is something to do with Text::Wiki. If you have more than 30K of text in an issue in flyspray ~ which uses a wiki library ~ it will also fail to render.