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 :
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.
% 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.
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.
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.
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.
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.
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.
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.