Closed jkoudys closed 10 years ago
After implementing the form helper, I'm questioning if getThumbnailXhp() type of logic is ever necessary. The naming conventions would get confusing, and it might collide with overrides for the most commonly overridden classes. It's also not always true that one helper == one class.
The entire concept of a 'helper' is completely unnecessary from the view if you're on xhp, so I should be ignoring those. Instead, just define new elements, which may need to reference helper logic if that's the best way to get the data needed.
One thing I hadn't considered, is that these images will frequently just be added as style attributes, for when they're set as the background of an element. Perhaps the avatar is a more useful place to start.
Added the avatar in a57a40edb7362954d7b87e1b7f9d143194ab4d17 It's composed of the element, so any img attributes you add that aren't picked up will fall through to the rendered .
Simply call like:
and it will render the avatar for that user. If no avatar is set, it will fall back to the default image for avatars (same as the ConcreteAvatarHelper.)
I'll use this as a model for other helpers, but to start the image helper could be extended. Any helper that either does an 'echo' inside of it, or returns an html string, could be extended to return xhp instead. The xhp would then get its own element inside c5.php.
e.g. in ImageHelper, define getThumbnailXhp(), then inside :c5:thubmnail::render(), call ImageHelper::getThumbnailXhp(), so as to avoid anything but the simplest logic inside the c5.php itself.