rattail/appypod-rattail
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

[doc] In the process of updating documentation and website.

Browse source
This commit is contained in:
Gaetan Delannay 2012-09-12 00:23:34 +02:00
parent 6801188496
commit dc76ca542a
11 changed files with 144 additions and 68 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
bin/publish.py
View file

@ -354,9 +354,15 @@ class Publisher:
pageFile = file(pageFileName) pageFile = file(pageFileName)
pageContent = pageFile.read() pageContent = pageFile.read()
pageFile.close() pageFile.close()
# Extract the page title # Extract the page title (excepted for the main page, we don't
i, j = pageContent.find('<title>'), pageContent.find('</title>') # need this title, to save space.
pageTitle = pageContent[i+7:j] pageTitle = ''
if pageName != 'index.html':
i, j = pageContent.find('<title>'), \
pageContent.find('</title>')
pageTitle = '<tr><td align="center" style="padding: 10px; '\
'font-size:150%%; border-bottom: 1px black ' \
'dashed">%s</td></tr>' % pageContent[i+7:j]
# Extract the body tag content from the page # Extract the body tag content from the page
pageContent = self.pageBody.search(pageContent).group(1) pageContent = self.pageBody.search(pageContent).group(1)
pageFile = open(pageFileName, 'w') pageFile = open(pageFileName, 'w')
@ -489,7 +495,7 @@ class Publisher:
self.uploadOnPypi(tarball) self.uploadOnPypi(tarball)
if self.askQuestion('Publish on appyframework.org?', default='no'): if self.askQuestion('Publish on appyframework.org?', default='no'):
AppySite().publish() AppySite().publish()
if self.askQuestion('Delete locally generated site ?', default='yes'): if self.askQuestion('Delete locally generated site ?', default='no'):
FolderDeleter.delete(self.genFolder) FolderDeleter.delete(self.genFolder)
# ------------------------------------------------------------------------------ # ------------------------------------------------------------------------------

BIN
doc/AppyManifesto.odt Normal file
View file

Binary file not shown.

1
doc/appy.css Symbolic link
View file

@ -0,0 +1 @@
../gen/ui/appy.css

26
doc/gen.html
View file

@ -12,32 +12,6 @@
<p><b>gen</b> generates code that will run on <a href="http://plone.org" target="_blank">Plone 2.5</a>. Soon, the code will also be compatible with the latest Plone version. In my point of view, Plone 2.5 has reached the maximum level of complexity a Python developer may tolerate. Plone 2.5 heavily relies on Zope 2. While Plone 3 still runs on Zope 2, it has become heavily based on Zope 3 through the use of the "Five" product (=Zope 2 + Zope 3), that allows to use Zope 3 functionalities within Zope 2. Some people began to be angry about how complex certain tasks (like creating a portlet) became with Plone 3 (consult <a href="http://www.upfrontsystems.co.za/Members/roche/where-im-calling-from/meeting-plone-3" target="_blank">this</a>, for instance.) In order to fight against this trend, we decided to create a new code generator (a kind of concurrent to ArchGenXML so) that already makes sense for Plone 2.5 and will be more and more relevant for the current and future Plone versions, as the Plone community took the debatable decision to move to Zope 3.</p> <p><b>gen</b> generates code that will run on <a href="http://plone.org" target="_blank">Plone 2.5</a>. Soon, the code will also be compatible with the latest Plone version. In my point of view, Plone 2.5 has reached the maximum level of complexity a Python developer may tolerate. Plone 2.5 heavily relies on Zope 2. While Plone 3 still runs on Zope 2, it has become heavily based on Zope 3 through the use of the "Five" product (=Zope 2 + Zope 3), that allows to use Zope 3 functionalities within Zope 2. Some people began to be angry about how complex certain tasks (like creating a portlet) became with Plone 3 (consult <a href="http://www.upfrontsystems.co.za/Members/roche/where-im-calling-from/meeting-plone-3" target="_blank">this</a>, for instance.) In order to fight against this trend, we decided to create a new code generator (a kind of concurrent to ArchGenXML so) that already makes sense for Plone 2.5 and will be more and more relevant for the current and future Plone versions, as the Plone community took the debatable decision to move to Zope 3.</p>
<h1>Before starting, let's get bored by some (counter-)principles that underlie gen</h1>
<p>If you have strict deadlines, skip this.</p>
<ul>
<li><b>The code-centric approach</b>. Other approaches for generating code like the idea of starting from some abstract vision like a (graphical) model (boxes, arrows, things like that); from it, tools generate code skeletons that need to be completed in a subsequent "development" phase. Such "transformational" approaches (I vaguely know some buzzwords for it: MDA, MDD I think) may even count more than two phases and manipulate different models at different abstraction levels before producing code (I am not joking: I've learned that at the university). Such approaches spread the information in several places, because every model or representation has limited expressivity. It produces redundancy and eventually leads to maintenance problems. It violates the <a href="http://c2.com/cgi/wiki?DontRepeatYourself" target="_blank">DRY principle</a>, which is closely related to our <a href="index.html">null-IT principle</a>. On the contrary, <b>gen</b> knows only about code. The "model" you write is a simple Python file or package. Being written in a high-level programming language, it does not constrain your expressivity in any way. More important: this code *is* the running code, and thus the only place where you describe your software. Simply, "wrappers" are added to it in order to plug him into the low-level Plone and Zope machinery. A gen-powered Python program acts like a comedian manipulating a tuned marionette: simple moves from the comedian produce complex, cascading and funny behaviours at the puppet level. Moreover, a code-based approach has the following benefits:</li>
<ul>
<li>when using a graphical model, you are emprisoned into a poorly expressive notation. Let's take an example. If you express a state machine with a UML state diagram, how will you be able to define another state machine based on the previous one? If you express it with code, it is as simple as using class inheritance. Typically, with appy.gen, you may achieve nice results like workflow inheritance; it is completely impossible with ArchGenXML. Of course, using graphical models for communicating or focusing on some parts of your program may be very valuable; this is why we foresee to implement model generation (class diagrams, statecharts, etc) from a appy.gen application. This is our way to see how to use graphical models: as views generated from the code. We don't believe at all in approaches like generating code from models or round-trip engineering.</li>
<li>when using some centralized code repository like subversion, a UML model, for example, is typically stored as a binary file. So it is impossible to work concurrently on various parts of it; nor is it possible to view who has changed what in it, etc;</li>
<li>factoring similar groups of attributes or doing other intelligent treatment on a graphical model is not possible;</li>
<li>there is no need to write and maintain a model parser (like XMI);</li>
<li>yes, you can use cut-and-paste with any text editor! If you want to do similar things with a model, you will probably need to buy some expensive UML editor;</li>
</ul>
<li><b>Violating the model-view-controller pattern (and a lot of other patterns, too)</b>. Design patterns are elegant low-level constructs used to overcome the limitations of programming languages (ie statically-typed languages like Java) or frameworks. Using them implies adding classes just for making the plumbery work; it augments code complexity and, again, spreads information at several places. Separating code describing data from code presenting it produces the same problem. appy.gen takes the approach of grouping everything at the same place. For example, information that dictates how a given field will be displayed is part of the field definition.
</li>
<li><b>All-in-one objects</b>. As a consequence of the two previous bullets, gen objects (which are Plain Old Python Objects: you do not even have to inherit from a base gen class!) are self-sufficient. If you want to understand some (group of) functionality within a well-designed gen Python program, you will not loose yourself walking through an intricate web of Python classes and XML definition files.
</li>
<li><b>Building complex and shared web applications</b>. While Plone and related tools are mainly targeted at building CMS websites (Content Management Systems = websites whose content may be edited by normal human beings), they provide poor support for those who want to build <i>complex</i> and <i>shared</i> web applications.
</li>
<ul>
<li>By <b>"complex"</b>, I mean real "business applications" (or "information systems", like accounting systems, HR systems or online booking systems) whose interfaces are web interfaces; a "CMS" website being a particular case whose main purpose is to provide information (the website of a city or a company, etc) with some limited degree of interaction with the user. Web business applications are characterized by (1) a rich conceptual model featuring a complex web of inter-related classes. Moreover, such applications also need (2) complex querying and reporting facilities, be it through-the-web or within generated documents. Standard Plone provides little support for both (1) and (2). For instance, the basic reference fields and widgets are embryonic (ie no built-in notion of order among references): creating complex inter-related objects is tedious. Standard Plone does not provide any standard document-generation solution and provides limited through-the-web querying facilities. appy.gen comes with a brand new ordered Reference field/widget that automates a lot of repetitive programming tasks and yields unexpected recurrent visualization possibilities. Through its integration with <a href="pod.html">appy.pod</a>, any gen-powered app is by default ready for document generation. gen also generates paramerized through-the-web views and queries.
</li>
<li>Currently, free software is widespread within the "IT infrastructure" (operating systems, networking components, web servers, application servers...) and contaminates more and more general-purpose software applications, like word processors, spreadsheets or multimedia players. For the most of it, the free movement currently reaches domains where requirements are either perfectly known by the developers themselves, deduced from observing proprietary software or part of some general cultural background. In order to raise freedom at the higher levels of business and innovation, we need new mechanisms allowing to tackle (business-)specific requirements, while maintaining the possibility to spread and <b>share</b> software from one organization to the other. appy.gen was built to cope with this new scale of challenges and proposes a set of built-in constructs for creating generic business kernels implementing common requirements and allowing to tailor it to the specific needs of a given organization. This work results from experience gained from a deep involvement in the <a href="http://plonegov.org" target="_blank">PloneGov community</a>, an international group of public administrations developing and sharing free software for their own needs. It also benefits from a close collaboration with several research initiatives (the <a href="http://www.fundp.ac.be/en/precise/">PRECISE</a> research center and the <a href="http://moves.vub.ac.be/">MoVES</a> project) exploring Software Product Lines Engineering and inventing new ways to manage variability among software systems.
</li>
</ul>
</ul>
<h1>Getting started with gen</h1> <h1>Getting started with gen</h1>
<p>Read only this if you want to run a "Hello world" gen application on your machine. This section is dedicated to Joel, a tremedous application and framework tester that ignores the essence of his gift.</p> <p>Read only this if you want to run a "Hello world" gen application on your machine. This section is dedicated to Joel, a tremedous application and framework tester that ignores the essence of his gift.</p>

BIN
doc/img/gen.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 4.6 KiB

BIN
doc/img/pod.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 5.9 KiB

BIN
doc/img/star.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 310 B

69
doc/index.html
View file

@ -4,24 +4,55 @@
<link rel="stylesheet" href="appy.css" type="text/css"> <link rel="stylesheet" href="appy.css" type="text/css">
</head> </head>
<body> <body>
<p>Appy (<b>Ap</b>plications in <b>py</b>thon) is a bunch of tools distributed under the <a href="http://www.gnu.org/copyleft/gpl.html">GPL license</a> for developing applications in the <a href="http://www.python.org">Python</a> programming language. The framework features two main modules: <a href="gen.html"><b>gen</b></a> and <a href="pod.html"><b>pod</b></a>.</p> <!-- gen -->
<table cellpadding="0" cellspacing="0" align="center" width="80%" class="homeTable">
<h1>Developers, too, have the right to (h)appyness !</h1> <tr valign="top">
<td width="100px" align="center" style="font-size: 95%">
<p>Developers are often guys that live on another planet. Some think this is because software development is so exciting that everything else is poorly considered. At Null-IT software, we are deeply convinced that most developers do not enjoy themselves. They spend their lives together with complex problems that never go away from their minds. Nobody understands them. Their family? Their managers? Their clients? Their friends? No. Nobody. Nobody is able to imagine how huge and complex their tasks are. Consequently, what they do is underestimated. Worst: they can't communicate. Don't believe this is due to some intrinseque geek attitude. Their geekness results from the global incapacity to apprehend the very nature of their abilities. So they are forced to work harder while experiencing the true impossibility to share their permanent software experience. Of course, it may lead to social disasters.</p> <img src="img/gen.png" style="margin-bottom: 7px"/><br/>
<a href="gen.html">Get started</a><br/>
<p>By publishing this high-level, easy-to-use software construction kit, itself based on the tremendously productivity-boosting Python programming language, our crazy hope is to empower developers in such a way that they can leave more often their software prison and spend more time to discover real life.</p> <img src="img/star.png"/><br/>
<a href="genCreatingBasicClasses.html">User guide</a><br/>
<p>But (h)appyness has a price. Appy developers themselves accepted to pay. They have dealed their social life for one of the highest forms of social denial (sorry we can't reveal their working conditions), hoping their sacrifice will free the users of their work. So if one day you meet one of them, please be gentle and patient. But they will probably not discuss with you.</p> <img src="img/star.png"/><br/>
<a href="genCreatingAdvancedClasses.html">Reference guide</a>
<h1>The null-IT principle</h1> </td>
<td>
<p>Our action is guided by the following principle:</p> <b>gen</b> - Create web apps without knowing anything about web technologies. Just pure Python.<br/><br/>
You are a small team? A one-man-show? You are bored with technicals details preventing you
<h2>Information Technology (IT) should be as transparent and invisible as possible.</h2> from being creative and productive? You think conceptual but prefer coding over drawing? You want to do more
with less effort? You consider code as an art? You know that beauty comes with simplicity?
<p>While this may seem obvious, this principle is largely ridiculed by a great number of widespread technologies. I will mention here JEE and XSL-FO which were taken as counter-examples while developing <a href="pod.html">pod</a>. In the Python world, Zope 3, by trying to mimick the ridiculous JEE component-model where code is viciously chopped into undersized chunks interconnected by obscure XML declarations, falls unfortunately into this category as well. This is a pity seeing Zope guys trying to abandon the elegant, simple, powerful (in a word: Pythonic) design of Zope 2. But don't be scared! Many people think that Zope 2 will last for many years... Null-IT, with others, is working hard to fight against the generalized Balkanization attitude that undermine IT innovation. If you believe there is still place for hope, you came at the right site. It is time to discover <a href="gen.html">gen!</a></p> gen is made for you.<br/><br/>
<span style="font-size: 95%">
<p>The Appy framework needs Python 2.4 or higher.</p> <i>Some people say I will kill my business by publishing my secret weapon.
What more soothing suicide could I dream than Appy's wide adoption?</i>
<div align="right">Ga&euml;tan Delannay, risk manager.</div>
</span>
</td>
</tr>
</table>
<!-- pod -->
<table cellpadding="0" cellspacing="0" align="center" width="80%" class="homeTable">
<tr valign="top">
<td width="100px" align="center" style="font-size: 95%">
<img src="img/pod.png" style="margin-bottom: 7px"/>
<a href="pod.html">Get started</a><br/>
<img src="img/star.png"/><br/>
<a href="podWritingTemplates.html">User guide</a><br/>
<img src="img/star.png"/><br/>
<a href="podWritingAdvancedTemplates.html">Reference guide</a>
</td>
<td>
<b>pod</b> - Create dynamic documents in .pdf, .doc, .odt or .rtf in a few minutes.<br/><br/>
Producing dynamic reports can be SO simple. Use Libre/OpenOffice to create a document template, write some Python
expressions in it, launch pod and you're done. pod (<b>P</b>ython <b>O</b>pen <b>D</b>ocument)
wants to be as smaller as possible. Use your word processor as much as you can. Then switch to
pod only for the tricky things.<br/><br/>
<span style="font-size: 95%">
<i>During the dark ages of software development, creating a single page of report with JEE and XSL-FO
could took up to 2 weeks. Since Ga&euml;tan made pod, the same task can be done in ten minutes.</i>
<div align="right">Damien Hubaux, paradigm-shift detector.</div>
</span>
</td>
</tr>
</table>
</body> </body>
</html> </html>

53
doc/principles.html Normal file
View file

@ -0,0 +1,53 @@
<html>
<head>
<title>Principles behind Appy</title>
<link rel="stylesheet" href="appy.css" type="text/css">
</head>
<body>
<h1>Developers, too, have the right to (h)appyness !</h1>
<p>Developers are often guys that live on another planet. Some think this is because software development is so exciting that everything else is poorly considered. We are deeply convinced that most developers do not enjoy themselves. They spend their lives together with complex problems that never go away from their minds. Nobody understands them. Their family? Their managers? Their clients? Their friends? No. Nobody. Nobody is able to imagine how huge and complex their tasks are. Consequently, what they do is underestimated. Worst: they can't communicate. Don't believe this is due to some intrinseque geek attitude. Their geekness results from the global incapacity to apprehend the very nature of their abilities. So they are forced to work harder while experiencing the true impossibility to share their permanent software experience. Of course, it may lead to social disasters.</p><br/>
<p class="focus" align="center">By publishing this high-level, easy-to-use Python-based software construction kit, our crazy hope is to empower developers in such a way that they can leave more often their software prison and spend more time to discover real life.</p><br/>
<p>But (h)appyness has a price. Appy developers themselves accepted to pay. They have dealed their social life for one of the highest forms of social denial (we can't reveal their working conditions), hoping their sacrifice will free the users of their work. If, one day, you meet one of them, please be gentle and patient. But they will probably not discuss with you.</p><br/>
<h1>The null-IT principle</h1>
<p>Our action is guided by the following principle.</p>
<p class="focus" align="center" style="margin: 10px">Information Technology (IT) should be as transparent and invisible as possible.</p>
<p>While this may seem obvious, this principle is largely ridiculed by a great number of widespread technologies. I will mention here JEE and XSL-FO which were taken as counter-examples while developing <a href="pod.html">pod</a>. In the Python world, Zope 3, now renamed BlueBream, by trying to mimick the JEE component-model where code is viciously chopped into undersized chunks interconnected by obscure XML declarations, falls into this category as well. It is time to fight against the generalized Balkanization attitude that undermine IT innovation!</p><br/>
<h1>Some (counter-)principles that underlie gen</h1>
<p><a href="gen.html">gen</a> is the largest part of Appy and allows to build web apps. The idea is to generate, from a set of simple Python classes, a complete web app, from the web user interface to the database. Integration with appy.pod allows to generate documents from the web app. gen currently generates web apps for the Zope web application server. We had the following ideas in mind while developing it.</p><br/>
<ul>
<li><b>The code-centric but conceptual approach</b>. appy.gen works at a higher level of abstraction than most other frameworks or approaches. With gen, you are not going to write a function that returns dynamic HTML when some URL is hit. You are going to define classes and relationships, and methods will be like hooks that will react when some events occur (an object is created, edited, deleted, etc). You don't have to write a single line of HTML, CSS or Javascript to write basic Appy applications. Only pure Python. This is what I call <i>conceptual</i>. But unlike most conceptual approaches, you will not draw any diagram or anything that is not Python code. Pure Python, pure simplicity, no repetition, no transformation: optimal efficiency, optimal maintainability. Other conceptual approaches like the idea of starting from some abstract vision like a (graphical) model (boxes, arrows...); from it, tools generate code skeletons that need to be completed in a subsequent "development" phase. Such "transformational" approaches (I vaguely know some buzzwords for it: MDA, MDD I think) may even count more than two phases and manipulate different models at different abstraction levels before producing code (this is what I have learned at the university). Such approaches spread the information in several places, because every model or representation has limited expressivity. In my opinion, it produces redundancy and eventually leads to maintenance problems. It violates the <a href="http://c2.com/cgi/wiki?DontRepeatYourself" target="_blank">DRY principle</a>, which is closely related to our Null-IT principle (see above) On the contrary, gen knows only about code. The "model" you write is a Python package. Being written in a high-level programming language, it does not constrain your expressivity in any way. More important: this code <i>is</i> the running code, and thus the only place where you describe your software. Simply, "wrappers" are added to it in order to plug him into the low-level Zope machinery. A gen-powered Python program acts like a comedian manipulating a tuned marionette: simple moves from the comedian produce complex, cascading and funny behaviours at the puppet level. Moreover, a code-based approach has the following benefits:</li><br/>
<ul>
<li>when using a graphical model, you are emprisoned into a poorly expressive notation. Let's take an example. If you express a state machine with a UML state diagram, how will you be able to define another state machine based on the previous one? If you express it with code, it is as simple as using class inheritance. Typically, with appy.gen, you may achieve nice results like workflow inheritance. Of course, using graphical models for communicating or focusing on some parts of your program may be very valuable; this is why we foresee to implement model generation (class diagrams, statecharts, etc) from a appy.gen application. This is our way to see how to use graphical models: as views generated from the code. We don't believe at all in approaches like generating code from models or round-trip engineering.</li>
<li>when using some centralized code repository like subversion, a UML model, for example, is typically stored as a binary file. So it is impossible to work concurrently on various parts of it; nor is it possible to view who has changed what in it, etc;</li>
<li>factoring similar groups of attributes or doing other intelligent treatment on a graphical model is not possible;</li>
<li>there is no need to write and maintain a model parser (like XMI);</li>
<li>yes, you can use cut-and-paste with any text editor! If you want to do similar things with a model, you will probably need to buy some expensive UML editor;</li>
</ul><br/>
<li><b>Violating the model-view-controller pattern (and a lot of other patterns, too)</b>. Design patterns are elegant low-level constructs used to overcome the limitations of programming languages (ie statically-typed languages like Java) or frameworks. Using them implies adding classes just for making the plumbery work; it augments code complexity and, again, spreads information at several places. Separating code describing data from code presenting it produces the same problem. appy.gen takes the approach of grouping everything at the same place. For example, information that dictates how a given field will be displayed is part of the field definition.
</li><br/>
<li><b>All-in-one objects</b>. As a consequence of the two previous bullets, gen objects (which are Plain Old Python Objects: you do not even have to inherit from a base gen class!) are self-sufficient. If you want to understand some (group of) functionality within a well-designed gen Python program, you will not loose yourself walking through an intricate web of Python classes and XML definition files.
</li><br/>
<li><b>Building complex and shared web applications</b>. While some out-of-the-box tools like Plone, Joomla or Wordpress are mainly targeted at building websites of specific categories (CMS, blogs, etc), they provide poor support for those who want to build <i>complex</i> and <i>shared</i> web applications.
</li>
<ul>
<li>By <b>"complex"</b>, I mean real "business applications" (or "information systems", like accounting systems, HR systems or online booking systems) whose interfaces are web interfaces; a classical CMS-based website being a particular case whose main purpose is to provide information, with some limited degree of interaction with the user. Web business applications are characterized by (1) a rich conceptual model featuring a complex web of inter-related classes and (2) the need for complex querying and reporting facilities, be it through-the-web or within generated documents.
</li>
<li>Currently, free software is widespread within the "IT infrastructure" (operating systems, networking components, web servers, application servers...) and contaminates more and more general-purpose software applications, like word processors, spreadsheets or multimedia players. For the most of it, the free movement currently reaches domains where requirements are either perfectly known by the developers themselves, deduced from observing proprietary software or part of some general cultural background. In order to raise freedom at the higher levels of business and innovation, we need new mechanisms allowing to tackle (business-)specific requirements, while maintaining the possibility to spread and <b>share</b> software from one organization to the other. appy.gen was built to cope with this new scale of challenges and proposes a set of built-in constructs for creating generic business kernels implementing common requirements and allowing to tailor it to the specific needs of a given organization. This work results from experience gained from a deep involvement in the <a href="http://plonegov.org" target="_blank">PloneGov community</a>, an international group of public administrations developing and sharing free software for their own needs. It also benefits from a close collaboration with several research initiatives (the <a href="http://www.fundp.ac.be/en/precise/">PRECISE</a> research center and the <a href="http://moves.vub.ac.be/">MoVES</a> project) exploring Software Product Lines Engineering and inventing new ways to manage variability among software systems.
</li>
</ul>
</ul>
</body>
</html>

37
doc/template.html
View file

@ -12,23 +12,33 @@
</head> </head>
<body> <body>
<table class="main" align="center" width="100%" cellpadding="0" cellspacing="0"> <table class="main" align="center" width="100%" cellpadding="0" cellspacing="0">
<tr> <tr height="88px">
<td> <td>
<table width="100%" cellpadding="0" cellspacing="0"> <table width="100%" cellpadding="0" cellspacing="0">
<tr valign="top"> <tr valign="middle">
<td width="120px"><img src="img/appy.jpg"/> <td width="120px"><a href="/"><img src="img/appy.jpg"/></a>
</td> </td>
<td style="padding-top: 5px" align="right"> <td align="center">
<div class="focus">
Appy (<b>Ap</b>plications in <b>py</b>thon) is a
<a href="http://www.gnu.org/copyleft/gpl.html">GPL</a> framework for creating
<a href="http://www.python.org">Python</a> web apps.<br/>
But faster. A LOT faster!<br/>
<i style="font-size: 95%">Grasp its <a href="principles.html">technical principles &amp;
psychological effects</a> or download the <a href="AppyManifesto.odt">Appy manifesto</a>.
</i>
</div>
</td>
<td style="padding-left: 10px" align="center" width="120px">
<i> <i>
<a href="/">Home</a>&nbsp;– <a href="http://launchpad.net/appy">Download</a>&nbsp;&nbsp;<img src="img/star.png"/>&nbsp;
<a href="docToc.html">Doc</a>&nbsp;– <a href="https://answers.launchpad.net/appy">Forum</a><br/>
<a href="http://launchpad.net/appy">Download</a>&nbsp;– <a href="https://blueprints.launchpad.net/appy">To do</a>&nbsp;&nbsp;<img src="img/star.png"/>&nbsp;
<a href="https://answers.launchpad.net/appy">Forum</a>&nbsp;– <a href="javascript:sendMail('appyframework.org', 'info')">Contact</a><br/>
<a href="https://blueprints.launchpad.net/appy">To do</a>&nbsp;– <a href="https://launchpad.net/appy/+announcements">News</a>
<a href="javascript:sendMail('appyframework.org', 'info')">Contact</a>
</i> </i>
</td> </td>
<td align="right" width="150px"><img src="img/advisory.png"/> <td align="right" width="130px"><img src="img/advisory.png"/>
</td> </td>
</tr> </tr>
</table> </table>
@ -54,11 +64,10 @@
</td> </td>
</tr> </tr>
<!-- Content --> <!-- Content -->
<tr> {{ title }}
<td align="center" style="padding: 10px; font-size:150%; border-bottom: 1px black dashed">{{ title }}</td>
</tr> </tr>
<tr> <tr>
<td style="padding: 15px">{{ content }} <td style="padding: 10px 15px 15px 15px">{{ content }}
</td> </td>
</tr> </tr>
<tr> <tr>

12
gen/ui/appy.css
View file

@ -1,11 +1,11 @@
body { font: 75% Helvetica,Arial,sans-serif; background-color: #EAEAEA; body { font: 75% Helvetica,Arial,sans-serif; background-color: #EAEAEA;
margin-top: 18px} margin-top: 18px}
pre { font: 100% Helvetica,Arial,sans-serif; margin: 0} pre { font: 100% Helvetica,Arial,sans-serif; margin: 0}
h1 { font-size: 14pt; margin-bottom:4px;} h1 { font-size: 14pt; margin:6px 0 6px 0}
h2 { font-size: 13pt; margin-bottom:4px; font-style: italic; h2 { font-size: 13pt; margin:6px 0 6px 0; font-style: italic;
font-weight: normal; background-color: #d7dee4} font-weight: normal}
h3 { font-size: 12pt; margin-bottom:4px; font-weight: bold;} h3 { font-size: 12pt; margin:4px 0 4px 0; font-weight: bold;}
h4 { font-size: 11pt; margin-bottom:4px;} h4 { font-size: 11pt; margin:4px 0 4px 0}
h5 { font-size: 10pt; margin:0; font-style: italic; font-weight: normal; h5 { font-size: 10pt; margin:0; font-style: italic; font-weight: normal;
background-color: #d7dee4} background-color: #d7dee4}
h6 { font-size: 9pt; margin:0; font-weight: bold;} h6 { font-size: 9pt; margin:0; font-weight: bold;}
@ -135,3 +135,5 @@ img { border: 0; vertical-align: middle}
border-style: solid none; border-width: 1px medium; border-style: solid none; border-width: 1px medium;
color: #333333; line-height: 120%; color: #333333; line-height: 120%;
padding: 10px; margin: 10px 0 10px 0} padding: 10px; margin: 10px 0 10px 0}
.homeTable { background-color: #f2f5f8; border-top: 2px solid grey}
.homeTable td { padding: 10px 5px 10px 10px}