We all know how view overriding leads to plugin order dependencies and other problems, so how can we make views more easily customized?
What views are you most likely to override in your plugins and why?
Where could we split some views up, introduce nested views, or extension points?
Would you prefer certain output bits be conditional based on config/hooks?
info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by RaĆ¼l Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.
- Steve Clay@steve_clay
Steve Clay - 0 likes
- Menus are currently not generated with views and probably should be.
- It would be handy if more core forms had extension points inside the form and above the foot/submit button.
- Steve Clay@steve_clay
Steve Clay - 0 likes
- Juho Jaakkola@juho.jaakkola
Juho Jaakkola - 0 likes
- Matt Beckett@Beck24
Matt Beckett - 0 likes
- Matt Beckett@Beck24
Matt Beckett - 0 likes
- Steve Clay@steve_clay
Steve Clay - 0 likes
- Juho Jaakkola@juho.jaakkola
Juho Jaakkola - 0 likes
- Mohammed Aqeel@m.aqeel
Mohammed Aqeel - 0 likes
You must log in to post replies.To get us started:
page/elements/head has a lot of internal functionality that could potentially get important changes even within bugfix releases. We should do what we can to ensure devs don't have to override it in plugins.
I don't think form extension points are flexible enough. Instead I would like to see input fields as objects. Array of these objects could then be run through a plugin hook and plugins could add, remove, modify and sort the input fields as they like.
(I believe I have seen a ticket about this but I wasn't able to find it.)
That's a very drupal-like idea, but I love it and have been thinking about doing something similar as time permits. The drupal method uses arrays to represent elements, and on render each element is rendered in a view. Before the form is rendered the form array is passed through hooks so other plugins add to/remove from/edit the array before it gets rendered. Then on submission the form array is regenerated, and passed through validation hooks with the values.
Assuming validations all pass it's finally passed through 'submit' hooks for plugins to use the submitted data however they please.
Drupal tends to encourage plugins to use their own tables so requires a lot of SQL, but doing something similar in elgg with existing hooks/events should be doable. The obvious benefit is very flexible form building, no need for form view overrides allowing multiple plugins to affect the same form.
So in answer to Steve's question - forms (both core and those provided by other plugins) are what I tend to end up having to override.
I'm currently working with a plugin to modify the behavior of ColdTrick's file_tools and to add a single checkbox midway through the form I have to overwrite the entire form.
Ideally one could simply extract Drupal's form-building/client-validation to avoid reinventing the wheel. I've enjoyed using ZF1 forms on past (non-Elgg) projects and there's nothing stopping us from trying that out in Elgg. Just have to figure out the best combination of hooks when building the form/processing the action. The cool thing is you could practically implement a form and action handler without traditional Elgg action files/views.
Downside of programmatic forms tends to be display flexibility. ZF1 was a pain to customize and no doubt it's no small hurdle in Drupal.
Also the search forms should be unified. In one project the client wanted to customize the forms and make them look and work exactly the same way. This proved to be pretty annoying task as I had to override a lot of views. Maybe there should be 'input/search' view that all the search features would use?
Different search forms include: site search, user tag search, user name search, group tag search, etc. They all look a bit different, the views are located randomly and the html elements don't share the same classes.
+1 on passing the form fields through a plugin hook before rendering. Last time to include a captcha in a blog creation page, the entire view had to be overrided. If we can simply extend the view (or use a plugin hook) to inject / remove fields into a form, then it will be easy to manage.
Good point on input/search is Juho. I also faced that difficulty when the user requested to have a uniform search input view through out the site.