<div dir="ltr"><div>What I do not like the Plone when creating a theme,</div><div>use "<i>!important</i>" for almost all attributes of the css selectors ..</div><div>Maybe being a child in Plone, I'm working in the wrong way</div>

<div><br></div><div>In other CMS's, my favorite themes are those that CSS</div><div>only reset.css normalize.css or (my favorite)...</div><div><br></div><div>I think this would be a legal way for the initial themes Plone</div>

<div><br></div><div>Att.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/21 André Nogueira <span dir="ltr"><<a href="mailto:andre@simplesconsultoria.com.br" target="_blank">andre@simplesconsultoria.com.br</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I know a lot of people that just use Plone as a framework.<br>
Just edit one custom CSS file and transform the Frontend. No python<br>
and no PHP too :) And no XML :)<br>
This is the easyer and most important way to use Plone now<br>
<br>
To me, the basic steps for a new themer (for regular users not<br>
advanced users) is:<br>
1. Clone the default DIazo theme<br>
2. Try to find and change the logo<br>
3. Try to make some CSS chances<br>
<br>
Newcommer and basic users will never create a Diazo theme from the<br>
scracth. I dont see this action as a trivial action. Can be trivial<br>
just for advanced front end developers<br>
<br>
To me, trown all the Front end responsability to custom diazo themes<br>
could kill one of the Plone most important feature: Accessibility. We<br>
really need a strong starting point for new themes and for small<br>
customizations.<br>
<br>
To me, the only option to make plone more popular with the public you<br>
are aiming, is to reach this 5 points:<br>
<br>
1. One click install in production (something like Ploud or ready to<br>
use droplet in digital ocean or similar players)<br>
2. A great number of high quality themes.<br>
3. Very easy way to customize this themes (change logo and base<br>
colors). A editor based in LESS/SASS will be amazing.<br>
4. Very easy way to install addons<br>
5. very easy way to updat Plone and addons<br>
<br>
Only after that, Plone can become popular.<br>
<br>
Andre Nogueira<br>
<a href="mailto:andre@simplesconsultoria.com.br">andre@simplesconsultoria.com.br</a><br>
Simples Consultoria<br>
<a href="http://www.simplesconsultoria.com.br" target="_blank">www.simplesconsultoria.com.br</a><br>
Tel. <a href="tel:%2811%29%203898-2121" value="+551138982121">(11) 3898-2121</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, Nov 21, 2013 at 6:40 AM, Dylan Jay <<a href="mailto:djay@pretaweb.com">djay@pretaweb.com</a>> wrote:<br>
> Hi,<br>
><br>
> I'd be interested to know of those in this discussion how many do custom themes on a regular basis? ie take html/css or a PSD from a designer and construct a theme.<br>
> I suspect we're coming at this issue from a variety of different experiences and perhaps there are a lot of people on the plone developers list who consider themselves more of a python programmer than a FE developer.<br>


> I'm not saying that plone shouldn't be useful out of the box but I am saying it's a huge barrier to it's adoption by other that it is so hard to customise. Diazo is a massive improvement in this respect and I can only think that you must be doing very different work from us if you don't see that.<br>


> As an example, this week we're tutoring a fedral government department on how to create their own intranet. They've already installed, configured it, installed the plugins they want, setup the IA, dummy content etc. They have got a html/css design mockup in php from a web agency based on their ideas (we had no input). Now we'll do a day workshop with them using diazo, the theme editor and within the week they will have a working intranet. No python written, no php written. However the biggest hurdle will be integrating the editing UI, something that will be fixed with toolbar. The next biggest hurdle is to make sure all the bits of Plone UI and the right versions of jquery etc still work with the theme, or someone has to rewrite them.<br>


><br>
> Also trying to attract Python developers to Plone IMO is a waste of time. I understand the attraction. We love python, and we love other stuff python people do. However 99% of python programmers don't need or like a CMS. A CMS solves problems they don't have. Most python programmers are happy with static html generation like pelican. I think it's our pride that makes us want to be recognised within the Plone community for doing something worthy. I certainly feel that sometimes.<br>


> The solution however is to grow Plone itself into something widely used and admired. Not by pythonistas but by people who want to build websites quickly and that look awesome and have huge power underneath. At least then not only will we still have jobs working with software we love, by pythonistas would at least have to admit we created something popular even if it's not something they can use.<br>


> We won't create this popularity by trying to compete with flask or django or by make an out a kind of app container hybrid framework thing. If you want to build forms and apps etc that need complex FE widgets etc then you probably shouldn't be using a CMS IMO (Except if you want to do it TTW in which Plone/Plomino is great).<br>


> To do this we need to attract the very people that aren't here. Intergrators/themers. They don't care about Plone widgets and frameworks. They just want software that tick all the boxes for their clients/editors, and doesn't get in the way of implementing their design.<br>


><br>
> Dylan Jay<br>
><br>
> ---<br>
> <a href="http://www.pretagov.com" target="_blank">www.pretagov.com</a> - Secure SaaS for Government hosted locally.<br>
> P: <a href="tel:%2B61-2-9955-2830" value="+61299552830">+61-2-9955-2830</a>  <a href="tel:%2B44-87-0392-7071" value="+448703927071">+44-87-0392-7071</a> | <a href="http://linkedin.com/in/djay75" target="_blank">linkedin.com/in/djay75</a><br>


><br>
><br>
><br>
> On 20 Nov 2013, at 11:51 pm, Alex Clark <<a href="mailto:aclark@aclark.net">aclark@aclark.net</a>> wrote:<br>
><br>
>> On 11/20/13, 5:25 AM, Rok Garbas wrote:<br>
>>> Quoting Ryan Foster (2013-11-20 08:08:12)<br>
>>>> On Nov 19, 2013, at 6:46 PM, Dylan Jay <<a href="mailto:djay@pretaweb.com">djay@pretaweb.com</a>> wrote:<br>
>>>><br>
>>>>><br>
>>>>> On 20 Nov 2013, at 4:26 am, David Glick (Plone) <<a href="mailto:david.glick@plone.org">david.glick@plone.org</a>><br>
>>>>> wrote:<br>
>>>>><br>
>>>>>> On 11/19/13, 1:27 AM, Dylan Jay wrote:<br>
>>>>>>> On 19 Nov 2013, at 9:02 am, David Glick (Plone) <<a href="mailto:david.glick@plone.org">david.glick@plone.org</a>><br>
>>>>>>> wrote:<br>
>>>>>>><br>
>>>>>>>> On 11/18/13, 4:13 AM, Ramon Navarro Bosch wrote:<br>
>>>>>>>>> Sorry for the cross-posting!<br>
>>>>>>>>><br>
>>>>>>>>> I decided to write down my opinions after working at Arnhem sprint on<br>
>>>>>>>>> plone 5 theme, it's just a dump of what I have in mind :<br>
>>>>>>>>><br>
>>>>>>>>> <a href="http://bloc.jardigrec.cat/2013/11/plone-5-theme-plonethemebarceloneta.html" target="_blank">http://bloc.jardigrec.cat/2013/11/plone-5-theme-plonethemebarceloneta.html</a><br>


>>>>>>>>><br>
>>>>>>>>> Go go go !<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>> I think there's been a big thing missing from the discussion of<br>
>>>>>>>> plone.app.toolbar and isolating theme resources from Plone edit UI<br>
>>>>>>>> resources. That big thing is what it means for add-on authors: how can<br>
>>>>>>>> we make sure add-ons get a look and feel that fits with a site's custom<br>
>>>>>>>> theme?<br>
>>>>>>>><br>
>>>>>>>> Some add-ons only change things in the edit UI, and they'll be fine. But<br>
>>>>>>>> what about add-ons that provide their own portlets or viewlets, or<br>
>>>>>>>> a custom template that renders in the content area? These are common.<br>
>>>>>>> +1 it's something we haven't talked enough about.  However I'm -1 that<br>
>>>>>>> it's common.  These days a lot of the front end (FE) facing plugins can<br>
>>>>>>> be replaced by custom diazo based solutions quickly since most plugins<br>
>>>>>>> aren't generic enough to meet the needs of the theme. A good example is<br>
>>>>>>> a carousel.<br>
>>>>>>><br>
>>>>>>> I had a look at plugins we often use that are FE general plugins that do<br>
>>>>>>> require their own js and css.  - PloneFormGen - PloneBoard - Plomino<br>
>>>>>>> - collective.recaptcha - oembed and video stuff<br>
>>>>>>><br>
>>>>>>> Thats pretty much it. Some of these use their own frameworks, for<br>
>>>>>>> instance Plomino uses lots of JQuery UI so they don't rely on much from<br>
>>>>>>> Plone<br>
>>>>>><br>
>>>>>> Wow, I guess we totally disagree.<br>
>>>>>><br>
>>>>>> Here are some other examples: - collective.cover - Solgema.fullcalendar<br>
>>>>>> - collective.plonetruegallery - eea.facetednavigation - cioppino.twothumbs<br>
>>>>>><br>
>>>>>> If addons no longer have a common library of markup they can expect to<br>
>>>>>> work and a consistent way to inject their own Javascript and CSS, I think<br>
>>>>>> we basically destroy the Plone add-on ecosystem. And I think that<br>
>>>>>> ecosystem is a huge part of Plone's continued success. Without it we only<br>
>>>>>> have an archaic web framework with a better-than-average editing UI.<br>
>>>>><br>
>>>>> I'm not saying we remove the consistent way to inject CSS and JS. I'm<br>
>>>>> saying we reduce as much as possible the opinion plone is putting on themes<br>
>>>>> about what CSS and JS they have to implement to make a site work.  It isn't<br>
>>>>> destroying the eco-system, it will make it stronger by making plugin<br>
>>>>> developers develop plugins which are designed to be themed as opposed to be<br>
>>>>> ones that can only be used on sites that look like Plone sites.  Most of<br>
>>>>> the above plugins install their own JS which may or may not be compatible<br>
>>>>> with your theme. For example collective.cover uses deco.js. Facetednav uses<br>
>>>>> it's own JS. The themer will have to go through a process of testing these<br>
>>>>> themes to make sure they work with their theme regardless of if they are<br>
>>>>> made to be compatible with the default plone theme or not. Your suggestion<br>
>>>>> doesn't prevent this unless we install every framework known. There really<br>
>>>>> isn't this "common" library of JS and CSS that works with all themes. By<br>
>>>>> enforcing such a set of CSS and JS you are instantly dating and<br>
>>>>> straightjacketing Plone to only be used by themers that know how to work<br>
>>>>> with Plones version of jquery, plones version or Jquery UI, plones version<br>
>>>>> of overlays etc. We keeping the club of people that can use Plone to just<br>
>>>>> us experienced Plone developers and missing the opportunity to make Plone<br>
>>>>> a system that is inviting for anyone to create a site or intranet.  I see<br>
>>>>> no problem with plugins being opinionated and installing their own CSS and<br>
>>>>> JS but obviously they have to do this at the risk of making it less likely<br>
>>>>> to be used by others since it will require more integration work. Make all<br>
>>>>> Plone sites look the same doesn't solve that problem.  For example Plone's<br>
>>>>> current use of jquery means that it's impossible to use custom JS in your<br>
>>>>> theme that requires a later version of jquery.  A Plone default theme<br>
>>>>> should be an "example" theme, not the basis for which all themes in Plone<br>
>>>>> should be built. I think it would be great to ship with multiple example<br>
>>>>> themes, perhaps based on different frameworks. If a plugin requires the use<br>
>>>>> of bootstrap or the CSS that comes with a certain theme then they should<br>
>>>>> make that an explicit dependency of their plugin. If we can automate that,<br>
>>>>> even better.<br>
>>>><br>
>>>> FWIW, I think flexibility can be a dangerous road when it comes to theming<br>
>>>> and can lead to issues with CSS and markup integrity. In general, if addons<br>
>>>> don’t have guidelines for markup and CSS they will make their own choices,<br>
>>>> which then makes them harder to support and theme.  A framework, in this case<br>
>>>> Bootstrap, might actually make theming Plone simpler and more approachable to<br>
>>>> new themers.<br>
>>>><br>
>>>> I truly don’t think it would be easier to theme Plone if it were less styled<br>
>>>> and addons provided less in terms of markup and styles.<br>
>>>><br>
>>>> I also don’t prefer it when addons decide to use their own opinionated<br>
>>>> frameworks that differ from plone core. In some cases it is justified but in<br>
>>>> others it is just an opinion that gets in the way of my integrating the addon<br>
>>>> into my theme.<br>
>>>><br>
>>>> If we provide logical defaults and guidelines for addons that are popular,<br>
>>>> well tested, neutral but attractive, and easy to customize with little<br>
>>>> effort, I believe we make things much easier for most themers.  A framework<br>
>>>> does that.  Bootstrap is the logical choice because it has the most backing<br>
>>>> and popular support.<br>
>>>><br>
>>>> Nothing about using Bootstrap as a starting point leads me to think that<br>
>>>> every site has to look the same.  If anything I think it will open the door<br>
>>>> for many more themes.  It does however, make it more difficult to use<br>
>>>> a different framework. Personally, I am fine with that trade off considering<br>
>>>> the simplicity that consistency and logical defaults might provide. My worst<br>
>>>> case scenario is that Plone makes no assertions about markup and styling and<br>
>>>> addons and themes diverge further than they already have.<br>
>>>><br>
>>>><br>
>>>>><br>
>>>>>><br>
>>>>>>> In terms of Plone itself there is very little that needs styling or JS<br>
>>>>>>> that is FE. Things like the contact form and public registrations we<br>
>>>>>>> should try and remove I believe. These things we almost always replace by<br>
>>>>>>> things like PFG as it gives more flexibility. We even do public user<br>
>>>>>>> registration with PFG now via collective.pfg.signup. Commenting is<br>
>>>>>>> perhaps another feature that requires special CSS. It's not something<br>
>>>>>>> I've ever used but perhaps it needs to go out of the core too? Live<br>
>>>>>>> search should be removed since it's a performance killer anyway and<br>
>>>>>>> almost no public site would want to turn this on unless they can<br>
>>>>>>> guarantee a very light load.  Once you take all of that out, I think you<br>
>>>>>>> only very basic styles such as those that can be set in tinymce.  I think<br>
>>>>>>> we should make this set of style as small as possible and should not<br>
>>>>>>> assume that any of p.a.widgets is available on the FE.<br>
>>>>>>><br>
>>>>>>>> Currently in Plone there is a de facto "standard library" of markup<br>
>>>>>>>> available to add-on authors. You can get an idea of what's included in<br>
>>>>>>>> this if you look at /test_rendering on a Plone 3 or Plone 4 site. As an<br>
>>>>>>>> add-on developer, I don't have to spend time on CSS or work with<br>
>>>>>>>> a designer, because I know what markup to use for a portlet or an alert<br>
>>>>>>>> message or a form, and can expect that all Plone themes will provide<br>
>>>>>>>> styles for that markup. This idea of a markup library is similar to<br>
>>>>>>>> Twitter Bootstrap, only ours has evolved organically over time rather<br>
>>>>>>>> than being carefully designed.<br>
>>>>>>>><br>
>>>>>>>> We can decide to change this library of markup patterns for Plone<br>
>>>>>>>> 5 (switch to Bootstrap, perhaps), if we want. But we can't stop having<br>
>>>>>>>> a library available altogether. The result would be that<br>
>>>>>>>> 1. Add-on authors have to spend time writing their own CSS<br>
>>>>>>>> 2. Different add-ons will not have a consistent look and feel<br>
>>>>>>>> 3. Themers will need to spend time overriding the styles for each<br>
>>>>>>>>    addon's markup, rather than merely implementing styles for the<br>
>>>>>>>>    standard markup<br>
>>>>>>> This side steps the issue that in reality themers spend that time<br>
>>>>>>> overriding the styles assumed by a plugin, whether its provided by Plone<br>
>>>>>>> or not. We don't live in a world where websites look like their CMS<br>
>>>>>>> anymore. We need to encourage an eco system of plugins that make<br>
>>>>>>> a minimum of style decisions, or make it really easy to diazo to make the<br>
>>>>>>> markup work with our chosen style framework such as bootstrap. If we try<br>
>>>>>>> to enforce a particular style framework on our themers we lose a lot of<br>
>>>>>>> potential users of Plone because Plone is too opinionated. Plone should<br>
>>>>>>> be the blanksheet that a designer can rely on to make any site they want.<br>
>>>>>>> This makes Plone a truely useful CMS that will stand out of the pack.<br>
>>>>>><br>
>>>>>> I still think using a framework makes it easier for the themer.<br>
>>>>><br>
>>>>> Yes but which framework? If plone relies of bootstrap 3 then we lock out<br>
>>>>> anyone that doesn't want to use bootstrap 3. What happens if a theme is<br>
>>>>> built on bootstrap 3 and plone 5 moves to bootstrap4?  Simpler more<br>
>>>>> independent plugins that are designed to not intefer with each other and<br>
>>>>> have simple html that is easy to theme. I think this is the way to go.<br>
>>>><br>
>>>> Then themes will need to be upgraded, however, the guidelines for how to do<br>
>>>> so might be clear and consistent across the board.<br>
>>>><br>
>>>>><br>
>>>>>> They can style the conventional markup, instead of figuring out what<br>
>>>>>> different markup each addon uses. It also provides greater flexibility.<br>
>>>>>> A site can be left without a custom theme, if it's look isn't important.<br>
>>>>>> Or the style framework can be replaced with custom CSS. Or a published<br>
>>>>>> theme addon can be used, since the markup is standard. If we don't try to<br>
>>>>>> define common markup, the *only* option is writing a custom theme. Yes,<br>
>>>>>> that happens for most sites by the time the site launches, but flexibility<br>
>>>>>> in when it happens is good.<br>
>>>>><br>
>>>>> I think there could be ways of handling this. For example a plugin could<br>
>>>>> come with same css which you insert into your theme. This is as opposed to<br>
>>>>> a plugin that fails to work at all if it doesn't include exactly the CSS<br>
>>>>> that came with it and therefore you have to fight against the plugin CSS to<br>
>>>>> be able to use the plugin with your custom theme.<br>
>>>><br>
>>>> Again, I think not using a framework encourages addons to include more CSS<br>
>>>> which is then harder to work with.  Of course, it could still be optional.<br>
>>>> But what about the markup?  Do we make the markup optional?  How would that<br>
>>>> work?  Well, the theme could include diazo rules to deal with the markup for<br>
>>>> the addon, but that is more work for the themer.  In most cases, logical<br>
>>>> defaults are good, especially when they are consistent and modern.  The<br>
>>>> problem with plone now is that it is neither consistent nor modern nor in<br>
>>>> some cases logical.<br>
>>>><br>
>>><br>
>>> i think we are forgetting what we are already doing.<br>
>>><br>
>>> default plone theme provides easier way to theme plone and allows addons to<br>
>>> know (almost) what kind of html/css to expect. in plone 4 we call it sunburst<br>
>>> in plone 5 we'll call it barceloneta. in the same manner addons in future could<br>
>>> expect barceloneta based theme. in case of high customization you will have to<br>
>>> manually fix things anyway.<br>
>>><br>
>>> barceloneta (as far as i know, ramon please correct me if i'm wrong) will be<br>
>>> based on bootstrap 3.if somebody prefers other framework please go ahead and<br>
>>> create your own theme in a similar fasion that braceloneta is doing it. so<br>
>>> there is no lockin.  i'm not huge fan of bootstap, but i recognize most of<br>
>>> designers/developers are familiar with it and should provide low entry barrier<br>
>>> and sane default.<br>
>>><br>
>>> also important to mention is that there is "minimal" theme which barceloneta is<br>
>>> based uppon -> no css only clean html which you can style from scratch.<br>
>>><br>
>>> i dont see much problem with addons space in future. they will continue to be<br>
>>> written in similar manner. what we will add is new area where addons can hook<br>
>>> into - let call it "backend" for now. that dom space has more predictable<br>
>>> css/html then frontend theme which changes from one to another project and can<br>
>>> more reliably hook into it.<br>
>>><br>
>>> so in short: we're *adding* possibility to addons to hook into backend. how<br>
>>> they hooked into frontend stays the same as in plone 4.<br>
>><br>
>><br>
>> Wow, I'm only loosely following this thread and I had to jump back in to<br>
>> Thunderbird to see the full discussion (I've been following things via<br>
>> Feedly/RSS for months.) :-) Anyway, first allow me to say this: I am<br>
>> very excited to see the discussion "heat up" over all things Plone 5 &<br>
>> in particular theming.<br>
>><br>
>> Obviously, we have a variety of different use cases "battling it out".<br>
>> This is our chance to define what we want Plone 5 to be and it's<br>
>> important we get it right NOW, because we're going to be living with<br>
>> Plone 5 LATER (for the next few years at least). Now, let me take a step<br>
>> back from the immediate theming discussion and reiterate what I want<br>
>> Plone 5 to be, FWIW:<br>
>><br>
>> - Lightweight, fast & modern, in the Python sense. This means: fewer<br>
>> Python packages and as much deprecation of old technologies as humanly<br>
>> possible. Ripping stuff out and turning stuff off MUST be the priority,<br>
>> and easily represents the most challenging work. `pip install Plone` is<br>
>> still my benchmark for this. Not because I love pip, but because it's<br>
>> now part of the Python core and we need to start paying more attention<br>
>> to it IF we want the Python community's attention[1]. I've begun some<br>
>> work on something called Plock to bridge the gap: `pip install plock`<br>
>> until `pip install Plone` actually works[2].<br>
>><br>
>> - Lightweight, fast & modern, in the Web sense. This means: using web<br>
>> technologies that web developers actually understand, are already<br>
>> familiar with, and can begin using quickly in the Plone context. I don't<br>
>> care about what framework we use (e.g. Bootstrap 3) as much as I INSIST<br>
>> the choice be lightweight, fast & modern in the Web sense. If that means<br>
>> we pick Bootstrap 3 now and a new framework for Plone 6, so be it.<br>
>> That's a lot of work, but at least it is' *definable* work. My eyes<br>
>> glaze over and roll back in my head whenever the discussion turns to<br>
>> "how do we bring the right HTML/CSS/JavaScript in from Plone to our theme".<br>
>><br>
>> Much like with Buildout, I worry our choice to rely so heavily on Diazo<br>
>> may have been a mistake. Instead, I think we should focus on discussing<br>
>> why we needed Diazo in the first place. What is Plone? Is it a system<br>
>> that enables inline editing of websites for every-theme-on-earth? Are we<br>
>> still aiming to perform every management task TTP (through-the-Plone)?<br>
>> If so, do we absolutely positively need Diazo to do this? If the answer<br>
>> is "yes", then I don't fully understand why. If the answer is "no", then<br>
>> I'm no better off, because I don't know how to implement the above<br>
>> feature set without Diazo (i.e. I need to strictly control Plone's UI<br>
>> and let folks 'tie in' via Diazo). Obviously mapping content to a theme<br>
>> is attractive, which is why we all went for it in the first place. But<br>
>> if you look at any other modern system that allows customization (e.g.<br>
>> GMail) they make it easy for you to customize AND strictly limit what<br>
>> you can customize. I worry that by relying on an increasingly more<br>
>> complex Diazo rule set we are complicating the stack and still not<br>
>> achieving the goal of everything TTP.<br>
>><br>
>> Lastly, I think we should make these decisions first then decide how to<br>
>> approach them in the current ecosystem. If we are confident about the<br>
>> direction, then we should have no issue documenting our progress and<br>
>> leading the users and integrators by example.<br>
>><br>
>><br>
>> Alex<br>
>><br>
>><br>
>> [1] This is just one case of many: "making Plone appealing to Python<br>
>> programmers." Arguably not even the most important, but one that I<br>
>> happen to care about.<br>
>><br>
>> [2] <a href="https://github.com/aclark4life/plock" target="_blank">https://github.com/aclark4life/plock</a><br>
>><br>
>> [3] Both great tools, but overkill in a lot of cases where folks just<br>
>> want to "do Python & Web".<br>
>><br>
>><br>
>><br>
>>><br>
>>><br>
>>> --<br>
>>> Rok Garbas - <a href="http://www.garbas.si" target="_blank">http://www.garbas.si</a><br>
>>><br>
>>> ------------------------------------------------------------------------------<br>
>>> Shape the Mobile Experience: Free Subscription<br>
>>> Software experts and developers: Be at the forefront of tech innovation.<br>
>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing<br>
>>> conversations that shape the rapidly evolving mobile landscape. Sign up now.<br>
>>> <a href="http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk</a><br>
>>> _______________________________________________<br>
>>> Plone-developers mailing list<br>
>>> <a href="mailto:Plone-developers@lists.sourceforge.net">Plone-developers@lists.sourceforge.net</a><br>
>>> <a href="https://lists.sourceforge.net/lists/listinfo/plone-developers" target="_blank">https://lists.sourceforge.net/lists/listinfo/plone-developers</a><br>
>>><br>
>><br>
>><br>
>><br>
>> ------------------------------------------------------------------------------<br>
>> Shape the Mobile Experience: Free Subscription<br>
>> Software experts and developers: Be at the forefront of tech innovation.<br>
>> Intel(R) Software Adrenaline delivers strategic insight and game-changing<br>
>> conversations that shape the rapidly evolving mobile landscape. Sign up now.<br>
>> <a href="http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk</a><br>
>> _______________________________________________<br>
>> Plone-developers mailing list<br>
>> <a href="mailto:Plone-developers@lists.sourceforge.net">Plone-developers@lists.sourceforge.net</a><br>
>> <a href="https://lists.sourceforge.net/lists/listinfo/plone-developers" target="_blank">https://lists.sourceforge.net/lists/listinfo/plone-developers</a><br>
><br>
> _______________________________________________<br>
> UI mailing list<br>
> <a href="mailto:UI@lists.plone.org">UI@lists.plone.org</a><br>
> <a href="https://lists.plone.org/mailman/listinfo/plone-ui" target="_blank">https://lists.plone.org/mailman/listinfo/plone-ui</a><br>
<br>
------------------------------------------------------------------------------<br>
Shape the Mobile Experience: Free Subscription<br>
Software experts and developers: Be at the forefront of tech innovation.<br>
Intel(R) Software Adrenaline delivers strategic insight and game-changing<br>
conversations that shape the rapidly evolving mobile landscape. Sign up now.<br>
<a href="http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Plone-developers mailing list<br>
<a href="mailto:Plone-developers@lists.sourceforge.net">Plone-developers@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/plone-developers" target="_blank">https://lists.sourceforge.net/lists/listinfo/plone-developers</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><font color="#003300">Felipe Duardo</font></div>
</div>