Kotti slots status?

[Lukas Zdych]

Hi,

I'm curious what is the status of slots usage in Kotti right now .. when I tried Kotti for the firstime (a fews days ago) + was playing with some add-ons and I found out that:

- if you register a widget to slot it show up on every page

- you can hardcode which slot the widget will be for or you can use kotti settings to provide options to e.g. which slot it is for, which content type it is for .. and in code you might be able to limit based on path in site etc...

- when enabled kotti's navigation widget it appears even if there is nothing to show resulting in displaying grey square on the righ page side

- when checking how add-ons are using them found that e.g. kotti_grid seems quite interesting but didn't work at all for me yet (widgets started to jump around page breaking layout etc.. currently useless for production)

So I was looking around and found some tries to improve slots in the past by pyramid_snippets or so .. but that seemed to be changed a year ago last time (if I remember well)..

To make it short what I'm missing in Kotti is context dependent widgets and guess why? .... I'm coming from Plone world .. ;-D .. here I would like to check if I missed something what might solve my need or if not then share my very raw idea how to implement something like kotti_snippets (which I'm more then happy to begin with).

1. define widget for every slot available in Kotti's UI which will take care about rendering snippets

2. add snippets management page (ideally accessible in context of any content type - not sure yet if that is possible to register it e.g. for Node)

- accessible by item in "actions" menu, content "views" menu or personal bar (doesn't really matter now)

- render pure layout with wiget in every slot (defined in point 1) but in something like "edit" mode where it will render list of assigned snippets and provide basic actions like add new, remove and reorder

3. snippet would be represented by something like a SnippetAssignment holding information about a snippet's assignment:

- slot it is assigned to

- context / content type / users group it is limited for

- snippet data (not sure if store it in the same model or keep here relation to s SnippetType model holding data which can be different for

different types of snippets) - I don't know SQL well so not sure if that is a good idea to have a table per snippet type or keep all snippet data in snippet assignment table e.g. as base64 and serialize / unserialize as a dict of snippet attributes

4. second part of the snippet would be a SnippetRenderer (just a view having a snippet assignment as context):

- renders snippet based on its own snippet type specific attributes

5. widget rendering snippets would check if snippet suppose to be rendered based on slot, cotnext or group ..etc .. limits rather then going into a renderer of every snippet and decide there (but snippet renderer base class might define a property: def available(self): return True which might be second level of checking if it should be rendered or not (Then every snippet type implmentation can override this property / method).

6. provide simple base classes for SnippetAssignment, SnippetRenderer, SnippetAddView, SnippetEditView so it is as easy as possible to create new types of snippets... 

Some of you might see that this is highly inspired by Plone's portlets but I still see something like snippets / viewlets / portlets how ever you call it as Major features of modern CMS so would like to give it to Kotti it if we can keep it simple and not complicate or slow down the whole machine.

Any comments or ideas welcomed!

Cheers

Lukas

[Andreas Kaiser]

Hi Lukas,

I started kotti_panels some months ago but didn't even finish the
specification phase yet: https://github.com/disko/kotti_panels. This
repo is merely a collection of ideas yet, but I think my ideas are
**very** similar to yours. There is literally nothing implemented yet.

Unfortunately I won't have time to work on kotti_panels in the short
(or even medium) term, but would highly appreciate if others could make
some progress on that topic, because I also think this is a must have
feature for every site with more than just basic content management
needs.

Feel free to fork, steal or take over kotti_panels or parts of it if
you think anything might be of actual use for you. Consider it being
under the WTFPL [1] ;)


Andreas

[1] http://en.wikipedia.org/wiki/WTFPL

[Andreas Kaiser]

On 19.05.2013, at 18:44, Lukas Zdych <lukas...@gmail.com> wrote:

> So I was looking around and found some tries to improve slots in the past by pyramid_snippets or so .. but that seemed to be changed a year ago last time (if I remember well)..

Forgot to mention in my previous reply: I use pyramid_snippets in a
current project to mimic a "portlet manager" on a per node base by
inserting something like "[nav]" in a document's body. Not exactly
user friendly, but it works and was easy to setup. kotti_panels would
have been what we want, but was way too far outside the budget of the
project to make it happen.


Andreas

[Daniel Nouri]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello.

I have a few thoughts I wanted to share about this, too.

On 05/19/2013 06:44 PM, Lukas Zdych wrote:
> I'm curious what is the status of slots usage in Kotti right now ..
> when I tried Kotti for the firstime (a fews days ago) + was playing
> with some add-ons and I found out that:
>
> - if you register a widget to slot it show up on every page
>
> - you can hardcode which slot the widget will be for or you can
> use kotti settings to provide options to e.g. which slot it is for,
> which content type it is for .. and in code you might be able to
> limit based on path in site etc...

Yes. This should give you the tools to build something more
sophisticated on top of it. (Which is basically Kotti's gist.)

I should say I'm a bit reluctant towards a one-solution-for-all
approach with regard to portlets. It turned out that for the biggest
Plone project I worked on (vienna.info), the stock Plone portlets
weren't a very good fit. So we ended up rolling our own portlet
implementation, which had features that were impossible to implement
with Plone's own portlets. For us, this worked quite well.

This is why I would suggest not aiming for putting your portlet
implementation into Kotti core, but rather to develop it as an add-on.

> - when enabled kotti's navigation widget it appears even if there
> is nothing to show resulting in displaying grey square on the righ
> page side

This is a bug that's easy to fix. A slot renderer can return None to
indicate that it doesn't want to be rendered. So there shouldn't be
any space, because the renderer will drop it. Please file a ticket,
or send a pull request if you feel up for it.

> - when checking how add-ons are using them found that e.g.
> kotti_grid seems quite interesting but didn't work at all for me
> yet (widgets started to jump around page breaking layout etc..
> currently useless for production)
>
> So I was looking around and found some tries to improve slots in
> the past by pyramid_snippets or so .. but that seemed to be changed
> a year ago last time (if I remember well)..

As Andreas said, this can be used today and it's working well for some
problems. We never got around to adding a menu for our rich text
editor to allow adding snippets in a more user-friendly way.

> To make it short what I'm missing in Kotti is context dependent
> widgets and guess why? .... I'm coming from Plone world .. ;-D ..
> here I would like to check if I missed something what might solve
> my need or if not then share my very raw idea how to implement
> something like kotti_snippets (which I'm more then happy to begin
> with).

It's interesting to note that before Plone 3, the portlet
implementation was based on persistent attributes: left_slots and
right_slots. As a developer, I liked this simple yet flexible
approach much more. I actually consider Plone's new portlets a
failure. It might work okay for some use cases, but it's definitely
horrible to develop for (just count the number of classes in
plone.portlets).

Of course users sometimes want to be able to assign the slots through
a web interface, and that's what the old Plone portlet implementation
didn't do, unless you considered the ZMI's property UI sufficient.
:-)

However, there were products based on top of left_slots and
right_slots that solved this problem quite nicely. One was
SimplePortlet, which I personally used with success.

> 1. define widget for every slot available in Kotti's UI which will
> take care about rendering snippets
>
> 2. add snippets management page (ideally accessible in context of
> any content type - not sure yet if that is possible to register it
> e.g. for Node)

Sure that's possible.

> - accessible by item in "actions" menu, content "views" menu or
> personal bar (doesn't really matter now) - render pure layout with
> wiget in every slot (defined in point 1) but in something like
> "edit" mode where it will render list of assigned snippets and
> provide basic actions like add new, remove and reorder
>
> 3. snippet would be represented by something like a
> SnippetAssignment holding information about a snippet's
> assignment: - slot it is assigned to - context / content type /
> users group it is limited for

I don't think that being able to filter by context or users is
something that you'll want to be able to define in the web UI. If you
have a portlet that wants to be rendered on the side of a specific
content type only, or only for a specific role, then most of the time
this logic is best implemented on the file system.

> - snippet data (not sure if store it in the same model or keep
> here relation to s SnippetType model holding data which can be
> different for different types of snippets) - I don't know SQL well
> so not sure if that is a good idea to have a table per snippet type
> or keep all snippet data in snippet assignment table e.g. as base64
> and serialize / unserialize as a dict of snippet attributes

You could use a JSON field for that. Kotti itself uses that to store
'Node.annotations'.

> 4. second part of the snippet would be a SnippetRenderer (just a
> view having a snippet assignment as context): - renders snippet
> based on its own snippet type specific attributes
>
> 5. widget rendering snippets would check if snippet suppose to be
> rendered based on slot, cotnext or group ..etc .. limits rather
> then going into a renderer of every snippet and decide there (but
> snippet renderer base class might define a property: def
> available(self): return True which might be second level of
> checking if it should be rendered or not (Then every snippet type
> implmentation can override this property / method).
>
> 6. provide simple base classes for SnippetAssignment,
> SnippetRenderer, SnippetAddView, SnippetEditView so it is as easy
> as possible to create new types of snippets...

Your approach seems quite reasonable to me. Except I'm a little
scared of too many classes. You'll maybe need to drink some more of
Kotti's 'simple is better than complex' kool-aid in the course of
doing this. :-)

> Some of you might see that this is highly inspired by Plone's
> portlets but I still see something like snippets / viewlets /
> portlets how ever you call it as Major features of modern CMS so
> would like to give it to Kotti it if we can keep it simple and not
> complicate or slow down the whole machine.

I agree that user-assignable portlets are nice, but it's not what I
consider a major feature of a CMS. I consider portlets themselves a
major feature, not the web UI to put them where you want.

But that's debatable and of course it's something that a lot of people
want, so I'd like to encourage you to build something openly that
solves this problem. With your work and feedback from the community,
I think we could get ourselves a very nice add-on, and one that a lot
of people would use.


Cheers
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlGbWv8ACgkQi2kx5isbD8x4NgCfesFEiQYbWowYoId9/0vzDG/b
WgAAoIaXY+6UIoCICTRjlQxOxZT0HA/m
=km7Z
-----END PGP SIGNATURE-----

[Marco Scheidhuber]

Hi Lukas,

On 05/19/2013 06:44 PM, Lukas Zdych wrote:

> - when enabled kotti's navigation widget it appears even if there is
> nothing to show resulting in displaying grey square on the righ page side

As Daniel mentioned this is a bug. I'm working on a new release of
kotti_navigation where
this is already fixed, but I can't say when this will be ready.

> - when checking how add-ons are using them found that e.g. kotti_grid
> seems quite interesting but didn't work at all for me yet (widgets
> started to jump around page breaking layout etc.. currently useless
> for production)

kotti_grid is currently released as alpha and it isn't used in
production yet.
Would be great if you can open an issue with the problems that occurred
and your
system configuration here: https://github.com/j23d/kotti_grid/issues

> So I was looking around and found some tries to improve slots in the
> past by pyramid_snippets or so .. but that seemed to be changed a year
> ago last time (if I remember well)..

pyramid_snippets was build to be able to use snippets in the body text
of documents.
If I remember right this idea was adopted from Typo3, but I don't know
this CMS to
say if this is right. I use it in a project to exactly solve this problem.

> To make it short what I'm missing in Kotti is context dependent
> widgets and guess why? .... I'm coming from Plone world .. ;-D .. here
> I would like to check if I missed something what might solve my need
> or if not then share my very raw idea how to implement something like
> kotti_snippets (which I'm more then happy to begin with).
>

> [...]
I'm not familiar with the current implementation of kotti_panels, but it
was created
from Andreas with the same intentions in mind an could be a good
starting point.
I also like the name panels more than snippets, at least there would be
no name
clashes with the same name for different ideas.

Cheers,
Marco

[Andreas Kaiser]

On 21.05.2013, at 15:47, Marco Scheidhuber <johndoe...@googlemail.com> wrote:

>> So I was looking around and found some tries to improve slots in the past by pyramid_snippets or so .. but that seemed to be changed a year ago last time (if I remember well)..
> pyramid_snippets was build to be able to use snippets in the body text of documents.
> If I remember right this idea was adopted from Typo3, but I don't know this CMS to
> say if this is right. I use it in a project to exactly solve this problem.

Doesn't really matter, but I think it was some wiki where the idea came from.

>> To make it short what I'm missing in Kotti is context dependent widgets and guess why? .... I'm coming from Plone world .. ;-D .. here I would like to check if I missed something what might solve my need or if not then share my very raw idea how to implement something like kotti_snippets (which I'm more then happy to begin with).
>>
>> [...]
> I'm not familiar with the current implementation of kotti_panels,

There is none… :(

[Daniel Nouri]

On Tue, May 21, 2013 at 3:47 PM, Marco Scheidhuber
<johndoe...@googlemail.com> wrote:
>> So I was looking around and found some tries to improve slots in the past
>> by pyramid_snippets or so .. but that seemed to be changed a year ago last
>> time (if I remember well)..
>
> pyramid_snippets was build to be able to use snippets in the body text of
> documents.
> If I remember right this idea was adopted from Typo3, but I don't know this
> CMS to
> say if this is right. I use it in a project to exactly solve this problem.

I think the idea came from Wordpress' Shortcodes:
https://codex.wordpress.org/Shortcode


Daniel

[Daniel Nouri]

On Tue, May 21, 2013 at 3:50 PM, Andreas Kaiser <di...@binary-punks.com> wrote:
>
> On 21.05.2013, at 15:47, Marco Scheidhuber <johndoe...@googlemail.com> wrote:
>
>>> So I was looking around and found some tries to improve slots in the past by pyramid_snippets or so .. but that seemed to be changed a year ago last time (if I remember well)..
>> pyramid_snippets was build to be able to use snippets in the body text of documents.
>> If I remember right this idea was adopted from Typo3, but I don't know this CMS to
>> say if this is right. I use it in a project to exactly solve this problem.
>
> Doesn't really matter, but I think it was some wiki where the idea came from.

Heh, now I remember Moinmoin has something similar too:
http://moinmo.in/HelpOnMacros

[Marco Scheidhuber]

Hey Daniel,

On 05/21/2013 01:31 PM, Daniel Nouri wrote:
>> - when enabled kotti's navigation widget it appears even if there
>> is nothing to show resulting in displaying grey square on the righ
>> page side
> This is a bug that's easy to fix. A slot renderer can return None to
> indicate that it doesn't want to be rendered. So there shouldn't be
> any space, because the renderer will drop it. Please file a ticket,
> or send a pull request if you feel up for it.

I checked your suggestion that a view that return None will not be
rendered in a slot. This won't work or at least not for me. When
you have a template renderer it expects a dictionary to render
the template so it fails on rendering, a String renderer will return
None as the String 'None' and that will be rendered in the slot.

The only chance I see with the current slot implementation to have
a widget not rendered is to raise a PredicateMismatch exception.
I'm missing something here?

Cheers,
Marco

[Daniel Nouri]

No, that's correct. I was confusing this with the slots
implementation before they were views. So yes, PredicateMismatch it
is. I'm adding a note to the docs.


--
http://danielnouri.org

[Lukas Zdych]

Hi all,

I'm very happy that my post started this discussion full of great ideas so I'll try to summarise it (as it turned into following my note about rendering empty navigation :-D ):

1. I like Andreas's response about "kotti_panels" and would like to fork it, start some research on the original idea and let him (or others) review my commits via pull requests as I'm very very new to Kotti and will appreciate if somebody living with Kotti some time already would keep an eye on me.. 

2. I also agree with most of Daniel's response about "keeping it simple":

- I didn't even think about having such a feature in core - I'm thinking about add-on to preserve developer's choice of final implementation

- I know Plone portlet's story very well (I'm living in Plone world for more then 8 years (ou man) :-) … making one portlet requires too much for sober developer - but what doesn't in current Plone / Zope :-D (actually that is major reason why I started to look for something different recent time) so .. yes KEEP IT AS SIMPLE AS POSSIBLE would be main goal in designing this add-on

- I'm very interested in difference between Plone's default portlets implementation and the one you mentioned in your project to learn from it

- I still think that panels (I like "panels" too) is a must have feature for a CMS even if it will stay optional and if I got it right Kotti is closer to CMS while Pyramid is a web framework below Kotti

3. the original reason I started this discussion for is to make Kotti (with optional add-on) pass the following example user stories:

AS a Webmaster,

I WANT to assign a panel to sidebar (or above content or footer etc.) and possibly configure its behaviour

SO THAT I can show e.g. navigation (contents of current web section) in a sidebar for every page in my website.

(this can pass right now by assigning a widget to slot in Kotti)

AS a Webmaster,

I WANT to assign a local panel to sidebar (or above content or footer etc.) and possibly configure its behaviour

SO THAT I can show e.g. list of related news to current document but only in e.g. "news" section or only in "news item" detail page.

(this is why I'm missing context / content type aware panels assignment)

AS a Webmaster,

I WANT to change order of assigned panels in particular website section or for particular content type

SO THAT I can show some panels like "featured content" in the top of e.g. sidebar where it is important but show it in the bottom where it's not so important. 

(If I'm right the order of widgets rendered in slots is now done by order of including add-ons in app.ini which implements particular widgets for slots)

These are very frequent in websites I was working on in past or I'm working now but I'm angry about how complicated it is in Plone.

I'm looking for some replacement where Kotti seems to me like very good choice - provides place where you need less customisations and can spend time on custom features implementation while in Plone you're spending ages by customising + including plenty of features you actually don't need / like and not talking how complicated it is to e.g. to change template for a widget or create a validator - who met with z3c.form knows what I'm talking about ;-).

Cheers

Lukas

[Daniel Nouri]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/21/2013 05:32 PM, Lukas Zdych wrote:
> Hi all,
>
> I'm very happy that my post started this discussion full of great
> ideas so I'll try to summarise it (as it turned into following my
> note about rendering empty navigation :-D ):
>
> 1. I like Andreas's response about "kotti_panels" and would like to
> fork it, start some research on the original idea and let him (or
> others) review my commits via pull requests as I'm very very new to
> Kotti and will appreciate if somebody living with Kotti some time
> already would keep an eye on me..
>
> 2. I also agree with most of Daniel's response about "keeping it
> simple":
>
> - I didn't even think about having such a feature in core - I'm
> thinking about add-on to preserve developer's choice of final
> implementation
>
> - I know Plone portlet's story very well (I'm living in Plone world

> for more then 8 years (ou man) :-) & making one portlet requires

> too much for sober developer - but what doesn't in current Plone /
> Zope :-D (actually that is major reason why I started to look for
> something different recent time) so .. yes KEEP IT AS SIMPLE AS
> POSSIBLE would be main goal in designing this add-on
>
> - I'm very interested in difference between Plone's default
> portlets implementation and the one you mentioned in your project
> to learn from it

I forget the details, but it was about inheriting portlets down. We
made a three-way option there: explicit blocking, leave as default
(inherit the option of displaying or not the portlet), or explicit
adding of a portlet. Also, the designer thought that the Plone
portlet UI wouldn't work for our customers.

My point is that regardless of how careful you are, you won't be able
to make a portlet implementation that works for everyone, and
sometimes it'll be easier to just roll your own, hence the reluctance
of putting this into the core.

> - I still think that panels (I like "panels" too) is a must have
> feature for a CMS even if it will stay optional and if I got it
> right Kotti is closer to CMS while Pyramid is a web framework below
> Kotti
>
> 3. the original reason I started this discussion for is to make
> Kotti (with optional add-on) pass the following example user
> stories:
>
> AS a Webmaster, I WANT to assign a panel to sidebar (or above
> content or footer etc.) and possibly configure its behaviour SO
> THAT I can show e.g. navigation (contents of current web section)
> in a sidebar for every page in my website. (this can pass right now
> by assigning a widget to slot in Kotti)
>
> AS a Webmaster, I WANT to assign a local panel to sidebar (or above
> content or footer etc.) and possibly configure its behaviour SO
> THAT I can show e.g. list of related news to current document but
> only in e.g. "news" section or only in "news item" detail page.
> (this is why I'm missing context / content type aware panels
> assignment)

Pyramid has 'context' and 'container' predicate arguments for views,
so if you're okay with doing configuration on the file system, you
could probably do this without writing any code (but ZCML ;-).

> AS a Webmaster, I WANT to change order of assigned panels in
> particular website section or for particular content type SO THAT I
> can show some panels like "featured content" in the top of e.g.
> sidebar where it is important but show it in the bottom where it's
> not so important. (If I'm right the order of widgets rendered in
> slots is now done by order of including add-ons in app.ini which
> implements particular widgets for slots)

This seems like a somewhat obscure use-case to me, but whatever makes
you happy. :-)

I guess the main feature of kotti_panels will be that you can assign
stuff through the web as opposed to in the config files.

> These are very frequent in websites I was working on in past or
> I'm working now but I'm angry about how complicated it is in
> Plone.
>
> I'm looking for some replacement where Kotti seems to me like very
> good choice - provides place where you need less customisations and
> can spend time on custom features implementation while in Plone
> you're spending ages by customising + including plenty of features
> you actually don't need / like and not talking how complicated it
> is to e.g. to change template for a widget or create a validator -
> who met with z3c.form knows what I'm talking about ;-).

Amen, brother. :-)

Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlGbqk4ACgkQi2kx5isbD8yUFACfReGC6JJuPfjL0s8qXijl630G
lzAAn1im35woamN8Ksdi1NNURZFLbOdW
=gm6v
-----END PGP SIGNATURE-----

[Lukas Zdych]

- I agree that UI for portlet management is confusing for users and take

some time to them to get used to use so let's learn from it 

My point is that regardless of how careful you are, you won't be able

to make a portlet implementation that works for everyone, and

sometimes it'll be easier to just roll your own, hence the reluctance

of putting this into the core.

- I agree too .. but we can have an optional add-on providing out-of-the-box

solution for most common use cases 

- I still think that panels (I like "panels" too) is a must have

feature for a CMS even if it will stay optional and if I got it

right Kotti is closer to CMS while Pyramid is a web framework below

Kotti

3. the original reason I started this discussion for is to make

Kotti (with optional add-on) pass the following example user

stories:

AS a Webmaster, I WANT to assign a panel to sidebar (or above

content or footer etc.) and possibly configure its behaviour SO

THAT I can show e.g. navigation (contents of current web section)

in a sidebar for every page in my website. (this can pass right now

by assigning a widget to slot in Kotti)

AS a Webmaster, I WANT to assign a local panel to sidebar (or above

content or footer etc.) and possibly configure its behaviour SO

THAT I can show e.g. list of related news to current document but

only in e.g. "news" section or only in "news item" detail page.

(this is why I'm missing context / content type aware panels

assignment)

Pyramid has 'context' and 'container' predicate arguments for views,

so if you're okay with doing configuration on the file system, you

could probably do this without writing any code (but ZCML ;-).

- yes if you want to limit it for particular content types but not content type

instances because you never know what title / id whatever your CMS user

type in or em I missing something? ;-) 

AS a Webmaster, I WANT to change order of assigned panels in

particular website section or for particular content type SO THAT I

can show some panels like "featured content" in the top of e.g.

sidebar where it is important but show it in the bottom where it's

not so important. (If I'm right the order of widgets rendered in

slots is now done by order of including add-ons in app.ini which

implements particular widgets for slots)

This seems like a somewhat obscure use-case to me, but whatever makes

you happy. :-)

- I have a lot experiences with non-profit or university websites where they

got used to use portlets a lot for "quickly" publish a piece of information as

static portlet for particular website sections from top or from some levels down

- the same for publishing quick image banners etc… if they're able to manage such

a content by themselves without requiring me to write a code or update

configuration then it saves my time a lot

- in  these cases I see a big potential if we can have simple solution how to assign

and manage panels and then develop just particular custom panels with as less

effort as possible (+ having some panels standard panels as add-ons e.g. static

text or image panel).

I guess the main feature of kotti_panels will be that you can assign

stuff through the web as opposed to in the config files.

These are very frequent in websites I was working on in past or

I'm working now but I'm angry about how complicated it is in

Plone.

I'm looking for some replacement where Kotti seems to me like very

good choice - provides place where you need less customisations and

can spend time on custom features implementation while in Plone

you're spending ages by customising + including plenty of features

you actually don't need / like and not talking how complicated it

is to e.g. to change template for a widget or create a validator -

who met with z3c.form knows what I'm talking about ;-).

Amen, brother. :-)

Daniel

- so I'll find some time asap (this weekend latest) to start with kotti_panels and will update you guys here once

I'll have something interesting to show

Cheers

Lukas

[Daniel Nouri]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/21/2013 07:26 PM, Lukas Zdych wrote:
> On Tuesday, May 21, 2013 at 7:09 PM, Daniel Nouri wrote:
>>

>> On 05/21/2013 05:32 PM, Lukas Zdych wrote: [...]

>>> AS a Webmaster, I WANT to change order of assigned panels in
>>> particular website section or for particular content type SO
>>> THAT I can show some panels like "featured content" in the top
>>> of e.g. sidebar where it is important but show it in the bottom
>>> where it's not so important. (If I'm right the order of widgets
>>> rendered in slots is now done by order of including add-ons in
>>> app.ini which implements particular widgets for slots)
>>
>> This seems like a somewhat obscure use-case to me, but whatever
>> makes you happy. :-)

> - I have a lot experiences with non-profit or university websites
> where they got used to use portlets a lot for "quickly" publish a
> piece of information as static portlet for particular website
> sections from top or from some levels down
>

> - the same for publishing quick image banners etc& if they're able

> to manage such a content by themselves without requiring me to
> write a code or update configuration then it saves my time a lot
>
> - in these cases I see a big potential if we can have simple
> solution how to assign and manage panels and then develop just
> particular custom panels with as less effort as possible (+ having
> some panels standard panels as add-ons e.g. static text or image
> panel).

This sounds all fine. I was specifically referring to showing the
same portlet sometimes on top, sometimes at the bottom. But I missed
your point, which was more about being able to assign portlets
generally.

> [...] - so I'll find some time asap (this weekend latest) to start

> with kotti_panels and will update you guys here once I'll have
> something interesting to show

Sounds great.

Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlGbr10ACgkQi2kx5isbD8xqXwCeOMa7afopNM/FAaEICxUU/XHy
6Y8An30KLLDvDgjHe2eYfx51YJtW/w84
=idKP
-----END PGP SIGNATURE-----