Re: A proposed goal for the Sea Sprint
Hi,
On 20 September 2012 23:03, Héctor Velarde
<hector.velarde@...> wrote:
> 1. it is based almost entirely on Deco, as André already clarified, and on
> David's blog post about using Deco without Deco
I think the ting I'm missing with it the most is the Deco editing
experience. I tried it for a few minutes and was fairly confused. I
appreciate it's not fully finished and possibly more of a framework
than a final product at this stage, but for me the major point of
excitement with Deco is from the end user perspective. It's about
making Plone easier to use and more powerful than most other CMSs out
there.
> 2. it has been working in production for two months with no major issues
> 3. it has a layout editor that is usable but have some drawbacks
> 4. it has a set of tiles that are usable; these include basic, collection,
> list, carousel, file, link, rich text and embed (some of them could have
> issues as we made some changes on the base tile)
This to me is the really huge win. I hope we can generalise these so
they work with any tile-based layout engine and maybe move them out of
c.cover.
> 5. we have solved the problem of images inside tiles
Great!
> 6. tiles have permissions that are managed by groups (columns)
> 7. tiles are configurable, you can declare what content can be dropped on it
> and what information the tile is going to display
> 8. we have a new widget for finding content to be dropped on tiles (see
> MultiContentSearchFieldWidget on collective.z3cform.widgets); this widget is
> used inside a "sreenlet" (a group of widgets to select the content to be
> dropped on the cover)
I guess this is the bit I don't fully understand, but I need to look
into it in more detail.
> what issues we have found?
>
> 1. we need have a clear mechanism for creating tiles, like we have on
> browser pages, viewlets and so on
What do you mean by this?
> 2. Deco should allow you to select among different responsive systems out
> there on an easy way; we can't be attached to Deco grid system (good point,
> Jean Michel)
I think this is nearly impossible with the way that Deco works. The
front-end JavaScript editor is all about manipulating a grid, and
supporting lots of different grid systems would be a nightmare.
However, we should make sure the layout generated by Deco isn't
incompatible with the major grid systems out there. And/or we should
switch to a more widely used one.
> 3. all tiles should support ESI (Edge Side Includes) out of the box; this is
> a must have for any front page or landing page on any site working behind a
> web application accelerator and there is no reason to have tiles not
> supporting it
plone.app.blocks should support this already.
> 4. we need to define a mechanism to test tiles; I was not able to find any
> example about it
Tiles are just views, really. I hope you can just test them like you'd
test any view.
I'm quite wary about adding a lot of "framework" around tiles. I think
that's what did for portlets.
> my personal views on some comments I read on the thread:
>
> 1. please kill the portlet history right now; we only need tiles and tiles
> are easy to write
> 2. I'm not really sure about replicating the functionality of a collection
> inside a tile; maybe I misunderstood the idea of this tile, but I think that
> can be solved having a collection and a tile that displays its results
In the "full Deco" vision, there would be no Collection content type.
Instead, you'd add a Page to your site where you wanted to display a
listing of content, add a Listing tile to it (and other tiles, for
content around the listing), configure it (much like the new
collections are configured now), and that would be that.
I don't think it's terribly user friendly to have to create a "secret"
collection somewhere in content space that you don't expect your users
to see, and then create a secondary content object (a page ala
collective.cover) to render it in situ.
> all of our code base and ideas are yours; use it. if we can move anything
> away from collective.cover to Deco we will be very happy; we will refactor
> our package after that.
>
> last thing I want to say: Chris Calloway told me that maybe the Sea Sprint
> wouldn't be happening without the Cafecito Sprint.
Oh, I'm very sure. Anything to drive this story forward is important.
And, crucially, we need to solve people's real-world problems today to
evolve a vision, not set some grand vision for the far-future and do
nothing until we've got it perfectly built. I think we do need a bit
of a vision, though, even if it changes over time.
> I've been working with the people behind this project for over a year and I
> feel like a very privileged guy.
>
> you probably don't know many of them; most of them are pretty young, but
> they are very skilled and professional: we have, together, more than 30
> years of Plone development experience in different areas.
The code looked really good, certainly.
> for me it has been difficult to make some of them understand the importance
> of being known and the imperative of participate on the discussions of this
> list about the future of Plone.
I think "being known" doesn't mean you're part of some clique. It
means that you've contributed code, documentation, support on the
forums etc.
> this is the first time Gonzalo is going to be with you and he's very excited
> about that; please talk to him: teach and learn.
Welcome
Are any of you coming to Arnhem?
Martin
------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html