Possible to set class or id of an individual slot?

[Stan]

One thing I can't figure out. I'd like to set the class or id of the
innermost division of a slot so that I can give it its own style. For
example, one slot with a yellow background for a post-it note, one
with a red border for a warning, etc.. The style has to be matched to
the nature of the content. It varies from one page to another, and
from one time to another, so I can't address this through page
templates. I would like to use RichText slots rather than HTML.

Is this possible, or is this one to add to the list of desired
features (and how can I work around it in the time being) ?

Thanks

[Tom Boutell]

Stan, are you saying you need some kind of UI for picking a color (or
perhaps a CSS class, so you can control more than color with it) for a
particular instance of a rich text slot?

How variable does this need to be? Would there be a set of possible
options, or would you be typing in colors on the fly / using a color
picker / etc?

Usually page templates are the right way to do this kind of thing.

> --
> You received this message because you are subscribed to the Google Groups "pkcontextcms" group.
> To post to this group, send email to pkcont...@googlegroups.com.
> To unsubscribe from this group, send email to pkcontextcms...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pkcontextcms?hl=en.
>
>

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

[Stan]

What I'd like to do is to predefine a discrete number of css styles
that could apply to slots. Then in the UI one could pick the style
(the class) that one would like to apply to a particular instance of a
slot. This would allow some dynamic style attribution within the scope
of the set. It would be very useful in situations where more
flexibility is required without having a large number of templates.
For example, the sticky note with the yellow background could be
anywhere on the page, and not in the same place on every page.

It seems to me that it would be simpler and more stylistically
integrated to choose from a coordinated set of classes than to define
all the style attributes one by one in the UI. I'm mainly thinking of
attributes such as border, background-image and background-color, but
it can include others of course.

> > For more options, visit this group athttp://groups.google.com/group/pkcontextcms?hl=en.

[Spike Brehm]

That seems pretty easy if you just include in pkContextCMSRichTextForm::configure() something like:

$this->setWidgets(
    array('value' => new sfWidgetFormRichTextarea(array(), $this->soptions)),
    array('classname' => new sfWidgetFormSelect(array('choices' => $classChoices), array())
);

and in the _editView.php do:

<select name="slotform-<?php echo $id ?>-classname">
    <option value="red">Red</option>
</select>

And in pkContextCMSRichText::executeEdit() method grab the value of the select and serialize that into the slot value which is stored in the DB, something like (Tom you may have to help me out with the details here so I don't mangle it too badly):

    $className = $this->getRequestParameter('slotform-' . $this->id . '-classname');
    $slotValue = $this->getRequestParameter('slotform-' . $this->id . '-value')
    $value = array('value' => serialize(array('classname' => $className, 'value' =>$slotValue));

in pkContextCMSRichTextComponents

  public function executeEditView()
  {
    $this->setup();
    // Careful, don't clobber a form object provided to us with validation errors
    // from an earlier pass

   $value = unserialize($this->slot->value);
   $this->classname = $value['classname'];

    if (!isset($this->form))
    {
      $this->form = new pkContextCMSRichTextForm($this->id, $this->options);
      $this->form->setDefault('value', $value['value']);
    }
  }

and in _normalView.php have something like:

<div class="richTextWrapper <?php echo $classname ?>">
<?php include_partial('pkContextCMS/simpleEditButton',
  array('name' => $name, 'permid' => $permid)) ?>

<?php if (!strlen($value)): ?>
  <?php if ($editable): ?>
    Click edit to add text.
  <?php endif ?>
<?php else: ?>
<?php echo $value ?>
<?php endif ?>
</div>

BUT this whole serialize/unserialize method is only if you don't want to edit your /config/doctrine/schema.yml to add a column to every slot for classname, which, after typing all that out, is probably the better method because it would allow you to do so for any/every slot in a more logical manner:

pkContextCMSRichTextSlot:
  columns:
    classname:
      type: string(255)

or for all:

pkContextCMSSlot:
  columns:
    classname:
      type: string(255)

and then ./symfony doctrine:build --all, ./symfony doctrine:data-load

Plus some other odds and ends to get it all working.  Sorry this is so discombobulated, at work and trying to hammer this out.  Ping me if for more clear instructions!  Tom, thoughts?

Spike

[Tom Boutell]

Spike, you have the general idea right and the implementation would
indeed be somewhat like that. What we plan to do is introduce a new
field in the slots table, 'variant', which would specify which of the
named variants of that slot should be used. The options corresponding
to that name will be set in the helper call that inserts the area in
question, or maybe from app.yml; that's a little up in the air just
yet.

We haven't yet decided whether you'll be able to change the variant
for an existing slot, notably including a standalone slot that is not
part of an area. That has advantages.

Two issues we're considering are the extra UI (where are we going to
put this selector? What will it look like?) and the possibility that
not all variants will be convertible to one another (I'm thinking we
should simply forbid that as bad practice - if it's so radically
different that it can't accept data originally intended for another
variant, make a new slot class).

Designing a feature and its interface is not a small issue around
here. Apostrophe is good because it is design-driven, not
developer-driven. The latter gets you Drupal. (:

But it's clear from the discussion on this list, and from questions
that have come up here in the office, that we really do need variants
and that they solve a number of common problems well.

I'm inclined to introduce variants sooner rather than later because
with our impending Great Renaming of the plugins there is a natural
opportunity to introduce a new column in the slots table with no
additional aggravation.

In general the purpose of variants is to get a variety of behavior
from a single slot type in ways that don't complicate the
implementation of the slot very much. Really big differences are
better served by creating a new slot class.

[Geoff DiMasi]

I think it is worth pointing out that we did open a ticket for this very issue last week on the Apostrophe Trac:
http://trac.apostrophenow.org/ticket/18

This discussion definitely is pushing us to try to get it down sooner.

Geoff

--
Geoff DiMasi

P'unk Avenue
215 755 1330

http://punkave.com

[cr0wn3r]

I hope I havent somehow misunderstood this thread, but isnt the
solution already there in the tools offered by fckeditor? You can set
predefined classes to appear in a dropdown box in the tool bar, so
therefore alowing the editor to wrap content in one of the predefined
style sets.

I think the tools offered by fckeditor are quite usable, although you
have to be careful with svn update with fck's config file being part
of the external.

On Jan 23, 3:10 am, Geoff DiMasi <ge...@punkave.com> wrote:
> I think it is worth pointing out that we did open a ticket for this very issue last week on the Apostrophe Trac:http://trac.apostrophenow.org/ticket/18
>
> This discussion definitely is pushing us to try to get it down sooner.
>
> Geoff
>
> --
> Geoff DiMasi
> P'unk Avenue

> 215 755 1330http://punkave.com

[Tom Boutell]

The FCK styles menu might be something to allow in a rich text slot,
but we're talking about styling the outermost container of the slot
itself. For instance, if I want one particular video slot in an area
to be aligned left, I can't currently do that.

[cr0wn3r]

Yeah, I understand the value of the development you guys are
suggesting. It would be great. I was just talking about the OP's
question. I think he could accomplish this, for rich text areas (as he
specified), for now using FCK.

On Jan 24, 2:36 pm, Tom Boutell <t...@punkave.com> wrote:
> The FCK styles menu might be something to allow in a rich text slot,
> but we're talking about styling the outermost container of the slot
> itself. For instance, if I want one particular video slot in an area
> to be aligned left, I can't currently do that.
>

> ...
>
> read more »

[Tom Boutell]

That would style the text inside the div, not the div itself. I
suspect that wouldn't be enough, but perhaps it would.

One problem is that as things stand you'd have to reconfigure our rich
text HTML filter to allow the proper styles to be specified freely,
which could have negative consequences as well. We prefer to keep rich
text simple and enhance slots to express more complex things without
the risk of trashing the layout etc.

punkave.com
window.punkave.com

[cr0wn3r]

It obviously wont style any of the pk divs, but it could be used to
wrap the text of the slot in a new innermost div called, say, "yellow
post-it", which might be an interim solution for the OP, allowing the
desired css to be applied to the slot. Would need to configure the
filter to allow 'class' to be specified.

It puts that control at the hands of the web admin which probably isnt
a good thing, so I offer it as a temporary solution without
disagreeing with anything already said!

On Jan 24, 11:53 pm, Tom Boutell <t...@punkave.com> wrote:
> That would style the text inside the div, not the div itself. I
> suspect that wouldn't be enough, but perhaps it would.
>
> One problem is that as things stand you'd have to reconfigure our rich
> text HTML filter to allow the proper styles to be specified freely,
> which could have negative consequences as well. We prefer to keep rich
> text simple and enhance slots to express more complex things without
> the risk of trashing the layout etc.
>

> ...
>
> read more »