Introduction

The aim of this development is to:

-       Increase performance

-       Start evolving towards platform independence. This means that soon Silex will be able to render sites in AS2, AS3, JS, or pure static HTML and that this development must lay some of the groundwork for that.

-       Make integration of third party components as easy as possible

-       Remove functionality from the core to make it lighter and push it towards plugins

-       Supercomponents. This is a separate development so it will not be specified here, but its future integration must be taken into account

-       Library of components in one swf file should be possible

Current state of things, and what the problems are :

-       A page is what you see at a url, for example yoursite.com/welcome/contact. This is rendered in Silex as pile of Layouts that contain Layers that contain media and components. Containers that are in a “Layer Skin” render Media, for example images and sound. Components are special SWFs that are loaded independently. It would be simpler and better to speak of Layers, SubLayers, and only components, not media.

-       Layouts are described in cumbersome XML files that no longer fit our needs and that are long to parse and manipulate. Furthermore the component properties are very linked to the virtual machine DOM. For example they contain “_x”, that is only x in AS2. There is therefore no way forward to work with AS3 or JS. The file format/system needs to be changed.

-       All components in Silex currently need to inherit the UiBase AS2 class. UiBase contains the arrays where the components and their properties are described. This is bad for performance, forces all components to be visual whereas there are now many non-visual components, and makes integration of third party functionality very difficult. We need to get rid of this dependence on UiBase and find another mechanism to describe components.

Proposal

Changes to the user experience

As mentioned above, a page will now be rendered as a pile of Layers that contain SubLayers. LayerSkins will be destroyed, and be replaced by a system where there is a mapping between the file extension of the media being used and the corresponding container component. For example, all files ending with “jpg”, ”png”, and “swf” can be rendered in the same way by the same container component that is responsible for static visual media. It could be called “ImageDisplay”. The current library will be enhanced with a separation between media and components. To add an image, the user will therefore have 2 possibilities: either add an “ImageDisplay” and configure it, or simply choose to insert the image and use the associated component. If by chance there are 2 components available to render the same file extension, the UI could offer a choice.  The only way for components that do not match a media type to be added is now through the component menu.

Changes in the architecture

The current layer skin players are moved to a plugin called “base_components”. This plugin contains the current renderers each in their own swf (or one single librairy ?), and one or more php files for the plugin integration.

A description of these components and how they can be used, configured etc. must be made available when editing the site, but not be necessary just to render them. Furthermore, the layer description file(s) should be useable to render the layer without a server and be planned for the multiplatform evolution.

The following data formats are to be applied:

Layers are described in one file per platform, using the following naming scheme: <layername>.<platform>.xml. For example: start.as2.xml. The structure of all of these files is the same down to component description, where the description of the component properties is specific to the DOM of the platform. For example the as2 file will contain _x if necessary, and the as3 file will contain x.

So for example:

<layer>

<subLayer id=”under”>

<components>

<component url=”/plugins/base_components/imagedisplay.swf” _x=”34” … more properties, ><htmlText>…</htmlText>…more properties…</component>

… more components

</components>

</subLayer>

… more subLayers

</layer>

Here is the content of the class ComponentDescriptor:

-       As2Url, as3Url, jsUrl: urls to the file to load when using it, depending on the platform. url relative to the root of the server. This information is used to see what platforms are supported.

-       Class: Name of the class contained in the file, where relevant

-       Name: A localized name to show in the components menu

-       Description: A localized description to show in the components

-       MediaTypes: an array of strings each containing an extension that is supported by the component. For example [“swf”, “png”, “jpg”]

-       Properties: An array of properties. See below.

-       getHtmlEquivalent which returns an html equivalent for the component (seo). Takes as input: the component id, the context (values for accessors, i.e. all layers data for the current page + publication config)

Events and methods and whatever other meta data we need can be added later.

Here is the content of the class PropertyDescriptor:

-       Name: Localized name

-       Description: Localized description

-       As2Name, as3Name, jsName : The matching property in each platform (e.g. _x / x / left )

-       Default: default value

-       Category: a category to use to sort the properties. TODO Could be replaced by tags, maybe.

-       isRegistered:  true/false should this be saved?

-       Miscellaneous meta data such as type, min/max values, min/max length etc.

Events and methods are not currently used, so they can be described later.

Furthermore, it must be easy to inherit descriptors. For example, the image renderer and the video renderer will have shared properties because they are both visual components. So a possible class inheritance structure would be :

ComponentDescriptorBase -> VisualComponentDescriptor-> ImageDescriptor and VideoDescriptor.

It makes sense to make ComponentDescriptorBase and VisualComponentDescriptor part of the basic framework so that components in other plugins such as OOF can use them to build their descriptors. ComponentDescriptorBase should handle localization using a standard yet to be defined. Each of these descriptor classes is defined in its own PHP file.

These components descriptors are only used by the wysiwyg, so they can be queried using a new service called component_descriptor_service. The method is called getDescriptors. It returns all available component descriptors.

Ensuite, pour les plus avancés, vous voulez disposer d’outils d’analyse. La version normale de Flash ne dit rien quand il y a un problème. Par contre la version Debug vous mettra un message d’erreur quand il détecte une erreur. Une règle de pouce: S’il y a eu une erreur, rafraîchissez tout de suite, Flash est en vrac et on ne peut plus rien en tirer de bon. Nous vous conseillons aussi FireBug, une extension Firefox, qui fait trop de choses pour qu’on puisse les lister là, mais vous permettra entre autres de suivre les requêtes envoyées au serveur. Il y a enfin une extension pour FireBug qui s’appelle FlashBug, qui permet de lire facilement les traces que vous aurez mis dans dans votre code Flash.

Il ne me reste plus qu’à vous souhaiter bon courage, et de vous inviter à partager vos questions et vos tuyaux dans les commentaires!

Nous pouvons en retour vous former, vous envoyer un pins au couleurs de silex, mettre un lien vers votre super site. Dites nous ce qui vous ferait plaisir

Nous prévoyons de lancer un système de plugins pour AMFPHP. C’est un sujet très geek et très dev, mais je me suis dit que ça pourrait en intéresser certains. Le post est ici sur mon blog, et la discussion est aussi lancée sur la mailing list amfp-cvs .

What?
AMFPHP is the best way for Flash to communicate with your PHP code. It understands the AMF data sent and received by Flash, and translates it into something your PHP code can work with. AMF allows for binary serialization of Action Script (AS2, AS3) native types and objects to be sent to server side services.

Why?
It is a critical component in a number of projects, so we decided to revive it. Many CMS can integrate with AMFPHP. Check http://www.amfphp.org/frameworks.html

Where?
www: http://amfphp.sourceforge.net/

Learn more: http://amfphp.sourceforge.net/about.htm

Please discuss in the comments.

Silex has evolved to a more structured framework made of javascript, ActionScript and php classes.

Ariel and Lex have implemented a system of hooks which make it possible to develop components, layonew reluts and tools which override the behaviour of Silex. Here are some interesting links to explain this « hook » technique we have set up in Silex :
- http://en.wikipedia.org/wiki/Hooking
- http://www.raymondselda.com/understanding-action-hooks-in-wordpress/
And in French :
- http://fr.wikipedia.org/wiki/Hook_(informatique)
- http://www.lautre-monde.fr/les-hooks-wordpress/

The first applications we did with it are very important : a new rich text editor which is the first step to porting Silex to AS3 and using tools made with Flex. It is possible to use this tool in a separate window, changing the way you use the tool boxes, and making it possible to use two screens with Silex. All the tools are being ported to AS3 and we will try to include several powerful ideas.

An other application is the « measure tool » which let you measure the execution time of several functions in Silex. We will use it to determine where we can optimize the code. And we have already found several things we can change to make Silex much more efficient so that it requires less memory to use it.

So please help us with your comments on the 1.5.4 beta release :
https://sourceforge.net/projects/silex/files/

Looking forward to « seeing » you on the forums,
The dev team.

Bonjour,

Silex recrute des stagiaires!

Voici les offres:

Stage Webmaster

Stage Webdesigner Maquettiste

Stage Integrateur Flash

2- les logs. dans le répertoire conf, il y a un fichier log.ini, qui contient la ligne

logLevel = DISABLED

Les logs sont donc désactivés. Si vous la remplacez par

logLevel = DEBUG

vous aurez des logs dans le répertoire logs/

Attention, c’est mauvais pour les performances et la sécurité, donc une fois que vous avez fini, remettez le comme avant!

Enfin, vous pouvez regarder les messages qu’échangent votre page Silex et votre serveur avec CharlesProxy.

======================================================================

So you’re upset with Silex or OOF? It deosn’t work and you don’t see why?

Here are some tools that will help you analyse the siutation. It’s a bit technical, but it will give you some clues on what is going on. We obviously advise you to check out the forums first to see if someone hasn’t already got the solution to your problem there.

1- The service debugger. It allows you to test if things are working ok on your server : http://wp-manager.silex-ria.org/?p=375

2- The logs. In the conf folder, you can find log.ini, and it contains the following line:

logLevel = DISABLED

logs are deactivated. But if you replace it with:

logLevel = DEBUG
You will find logs in the logs/ folder

Be careful, this is bad for performance and security, so once you’re done, put it back to how it was before!

Finally, you can check the messages that go between your silex page and your server with CharlesProxy.

Merci / Thanks Andy!