Doubts about how change a block plugin's position from an area to another

["Aurélio A. Heckert"]

Hi, sorry this late, but i back to the matrix today.

As Terceiro said once, the Block class itself must say "I can be placed 
there".

The plugin may simply define a block like "class MyBlock < Block"

And then, when listing the allowed blocks, we can ask:
Block.send(:subclasses).select{|b| b.can_be_placed_at(:center) }

Then we don't need to manage e list of Blocks and don't need to create 
new hotspots.

Hasta!
  Aurium

On 06-11-2013 17:46, Rodrigo Souto wrote:
> Nice work discovering the problem Fábio.
>
> So the extra_blocks hotspot is not adding the plugins blocks in the
> Box#acceptable_blocks method.
>
> To solve this problem we'll need to rewrite the logic of the
> Box#acceptable_{center,side}_blocks. The problem is that they are class
> methods and since the acceptable_blocks is now dynamically altered
> by the environment (that is the plugins that are enabled on the
> environment), they can no longer be Box class methods. They must become
> environment methods (I guess). And in the environment class you must
> include Noosfero::Plugin::HotSpot module. This module is going to allow
> the use of the "plugins.dispatch(:something)" calls you are looking for.
>
> OBS: the hot_spot module requires the class in which it's being added to
> define the method environment returning the related environment (this is
> already fixed in one of my coming patches which allows the call of
> plugins passing the environment as parameter, but for that's how it is)
> which will be kind of a strange thing to do on the environment model. =P
> You may wait for my fix or just define a method environment returning
> self for the moment.
>
> The second problem is that this extra_blocks infra allows the block to
> define specifically in which area it can be added and not only if it's
> in the center or the side. So instead of acceptable_{center,side}_blocks
> we should have methods related to areas (1,2,3). You may keep the
> current lists and just add them to the new methods you create to avoid
> repetition in the case of areas 2 and 3.
>
> I know it's a lot of things to mess around, but if you need some help
> look for me on the irc. Don't forget to write the tests before the
> changes.
>
> Fábio Teixeira escreveu isso ai:
>> We take a look at exemples. But we discovered that, what make a block move
>> from a area to another is the function "block_target" inside the helper
>> "BoxesHelper". This function only use the box.acceptable_blocks. So the
>> plugin extra_blocks function is only used to add the block,
>> in BoxOrganizerController.add_block.
>>
>> The function "block_target" is used inside the function "display_block_content"
>> on the "BoxesHelper", however we found that the only place where this
>> function is used is in "app/views/shared/block.rhtml".
>>
>> Is possible to add "plugins.dispatch(:extra_blocks)" inside the function
>> "block_target" ? We tried, but the helper does not have access to plugins...
>> _______________________________________________
>> Noosfero-dev mailing list
>> Noosfero-dev em listas.softwarelivre.org
>> http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/noosfero-dev
>
>
>
> _______________________________________________
> Noosfero-dev mailing list
> Noosfero-dev em listas.softwarelivre.org
> http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/noosfero-dev


-- 

*Aurélio A. Heckert (aka Aurium)*
http://softwarelivre.org/aurium
*COLIVRE --- Coop. de Tecnologias Livres*
http://colivre.coop.br

*Inkscape* --- Desenhe Livremente
http://inkscapeBrasil.org
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://listas.softwarelivre.org/pipermail/noosfero-dev/attachments/20131111/9fe74939/attachment.html>
-------------- Pr?xima Parte ----------
Um anexo n?o-texto foi limpo...
Nome: logoColivre_p.gif
Tipo: image/gif
Tamanho: 5576 bytes
Descri??o: n?o dispon?vel
URL: <http://listas.softwarelivre.org/pipermail/noosfero-dev/attachments/20131111/9fe74939/attachment.gif>