New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[com_fields] Subform support for custom fields #11905

Closed
awdhaan opened this Issue Sep 3, 2016 · 36 comments

Comments

8 participants
@awdhaan
Copy link

awdhaan commented Sep 3, 2016

Steps to reproduce the issue

  1. Login to the Site administration
  2. Navigate to Content > Fields
  3. Create a new field
  4. There is no option there to create a repeating field or subform

Expected result

subforms where introduced in Joomla 3.6, selecting from the list of available field types should include a repeater or subform like choice

Actual result

There is no subform

System information (as much as possible)

  • Joomla! Version Joomla! 3.7.0-dev Development [ Noether ] 5-August-2016 00:32 GMT
  • Joomla! Platform Version Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT

Additional comments

@brianteeman brianteeman changed the title Subform support for custom fields [com_fields] Subform support for custom fields Dec 3, 2016

@laoneo

This comment has been minimized.

Copy link
Member

laoneo commented Dec 14, 2016

This would mean you can select a XML file then which contains the subform?

@awdhaan

This comment has been minimized.

Copy link

awdhaan commented Dec 14, 2016

Yes, similar as in the current implementation (https://docs.joomla.org/Subform_form_field_type)
Context. The sites I build with Joomla require supportive information on an article level such as external links or references to other articles.

Cheers

@laoneo

This comment has been minimized.

Copy link
Member

laoneo commented Dec 14, 2016

For the editing part it would work. But how do you display then the data on the front?

@awdhaan

This comment has been minimized.

Copy link

awdhaan commented Dec 14, 2016

I suppose by processing the json through php

@laoneo

This comment has been minimized.

Copy link
Member

laoneo commented Dec 14, 2016

You need to know the structure and how to print each form field. For text field I think it would work but for example when you have a datepicker, then you don't want to display the date in the database format, you want to display it in the format of the user.

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 9, 2017

@laoneo have you had any chance to deal with this? If not, I could try to come up with a solution.

@laoneo

This comment has been minimized.

Copy link
Member

laoneo commented Jan 9, 2017

@frankmayer go for it.

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 19, 2017

@laoneo So, I finally found a little time to look into it... :)

Please excuse my long comment on this, but I think it is important to lay out and get a discussion going, which may result in a possible change for an issue in the current fields implementation (at least as far as I am concerned) before 3.7 is released.

I have thought of a way to implement a subform field, which would be able to include custom fields previously created, instead of reading an xml file. But with the fields` current form, it would introduce an added layer of complexity or if you like an "unintuitive" way of thinking for the end user. It might also introduce unnecessarily more complexity in the code.

Let my try to explain this...

Right now, the interpreted hierarchy of the custom fields is (extension) -> categories -> fields, with field group being a way of telling the form to render the field(s) into a separate tab of the item in question. While this is ok for simple implementations, it does not follow the "standard" that fields are part of a form, which is in turn part of the screen of whatever object it needs to manipulate.

If the interpreted hierarchy would be (extension) -> categories -> forms -> fields, instead, it would be much easier and more intuitive to implement (sub)forms in general. BTW, this is what I expected it to be, when I first read on the fields implementation.

Summing up some points that speak for the hierarchy change:

  • More intuitive (fields are part of a form)
  • If one would need to change the properties of a used field, at some point, to fit a specific purpose (or category), it might easier break things if the same field is also used for other categories, than if a field is part of a form, which has been designed from the beginning to be used for specific categories. It is easier to organize, manage (since it would be grouped on the target object) and for those reasons less error prone.
  • it makes things easier and more intuitive when a subform has to be implemented. Both for the user and concerning the complexity of the code to implement this.
    For example: If a subform is needed in a form, then a subform field can be used, which will point to the form we want to use.
    That (sub)form will have previously been setup to include one or more of the custom fields. Of course, a field would then only be able to belong to one form, in order to be able to save such subform data directly (not in json) into the EAV table (#__fields_values). This makes things also less error prone.
    BTW, since subforms may be repeatable, the EAV table would probably also need to have an arraykey column to be able to save such repeatable subform's field's value directly (not in json in the subform's field value column)

So, before I dive deeper, I would like to initiate a discussion on this matter.
I believe it is crucial to be discussed, as the status of development just passed alpha2 and beta1 is coming up fast.

@Bakual

This comment has been minimized.

Copy link
Contributor

Bakual commented Jan 19, 2017

(extension) -> categories -> fields

It's more like extension -> context (basically equates to a form) -> field group (fieldset / tabs) -> fields

@laoneo

This comment has been minimized.

Copy link
Member

laoneo commented Jan 19, 2017

I think @Bakual hit the nail. The context is what you call a form. After reading your comment, I guess a subform field can link to other fields or field groups. Out of that you will be able to generate the form of the field. Thanks to PR #12813, you are able to generate a subform in the existing form, there is no need for a XML file. Slowly a way arises how an implementation can look like.

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 19, 2017

Hmm, so the context would then for example be com_content.article? (Will look at that PR in a bit)

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 19, 2017

I guess a subform field can link to other fields or field groups

to other fields yes, to other field groups I am not sure. How would a reapeatable subform on a field_group look like?

It's more like extension -> context (basically equates to a form) -> field group (fieldset / tabs) -> fields

@Bakual I was depicting a simple form, but you are right the context would equate to a form. But still, you're missing the categories, which play a role, too. Depending from how one looks a it it's more like:
extension -> context (basically equates to a form) -> categories -> field group (fieldset / tabs) -> fields
or
extension -> categories -> context (basically equates to a form) -> field group (fieldset / tabs) -> fields

there is no need for a XML file.

Yes, that's why I wanted the hierarchy. If we don't need / don't want to implement an xml file, then the hierarchy should be as I described, via the form (as I descrived it) or context as @backual described it. And a field should that way belong only to exactly one form (context). Not to one or more categories. In the XML file you would have to obide to the hierarchy of the form or context and this should be the way, here, too.

@Bakual

This comment has been minimized.

Copy link
Contributor

Bakual commented Jan 19, 2017

But still, you're missing the categories, which play a role, too.

Categories aren't used in com_fields.

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 19, 2017

@laoneo

This comment has been minimized.

Copy link
Member

laoneo commented Jan 19, 2017

com_fields is not generating any file. Just to be clear on that point.

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 19, 2017

@laoneo I never said it did or it should.
I am just laying out that it would be better to have fields assigned to forms (context) like with the hierarchy in xml files.

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 19, 2017

@laoneo ... instead of directly to categories.
forms (contexts) could then be assigned to categories (in terms of used only when editing content in those categories).

@laoneo

This comment has been minimized.

Copy link
Member

laoneo commented Jan 19, 2017

If we don't need / don't want to implement an xml file

I thought you want to start creating files.

forms (contexts) could then be assigned to categories

I don't see here the use case. For me it is hard now to follow your thoughts.

@Bakual

This comment has been minimized.

Copy link
Contributor

Bakual commented Jan 19, 2017

@frankmayer Ah that. It's a filter based on the category of the item (eg article). It's not part of any hirarchy of com_fields.

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 19, 2017

(@laoneo while writing this new comment I saw your last one. Maybe this will explain things better..)

While thinking about the context = form association, I noticed that it actually is not quite correct, if there are several different forms that can be used on the same context but different categories.

For example, let's say I have a content category cars and a content category planes and I have fields that might be same or different between them.
For example:
maxSpeed would be a common field
maxHeight would be a field only to be used with planes.
gearType would be a field only to be used with cars.

Unless I have two different forms for the same context (com_content.article), I would also end up with a field of maxHeight in articles for cars and with the gearType field for planes.
The more intuitive way of doing this is to have two separate forms, with the correct fields for each content type. That would also mean that maxSpeed is defined twice. Once for cars and once for planes. That way, even if for example the maxSpeed field would be changed in its properties or even completely deleted for one content type (form), it would not hurt the other.

Just as a reference: In the few CCKs and other type of custom form or data extensions I have tested over the years, if I remember correctly, most - if not all, use the same logic principle:
A field is associated to exactly one form or content type.

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 19, 2017

@Bakual yes, but it plays a role of where fields are displayed and the context of the fields. Please read my prior comment in which I try to explain it better.

@Bakual

This comment has been minimized.

Copy link
Contributor

Bakual commented Jan 19, 2017

if there are several different forms that can be used on the same context but different categories.

It's always the same form (eg article). We just add fields to that form. We don't replace the form itself.
Based on the category of the item (article) there may be different fields added, but it's still the same (article) form.

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 19, 2017

As I stated in my example, you can have different types of articles (based on the categories filter). And it is more intuitive for the users to have different custom field forms (or form additions, if you like) for those different types, instead of assigning fields directly.
With my concern/proposal I am not trying to replace the basic form. I am just proposing to do a correct hierarchy for that, using forms -> fields. One that users will be able to

  • better understand
  • manage easier
  • make less errors with (as for example the point I described in my comment above)
@laoneo

This comment has been minimized.

Copy link
Member

laoneo commented Jan 19, 2017

So what you want is to assign field groups to categories or articles. But I guess this has nothing todo with this issue here?

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 19, 2017

As it happens, I currently am working on a project, that would rely on such functionality. This makes me and the users of my client, potential users of this implementation. And as a potential user of the current state, I have raised my concerns and a proposal on this.
If the community thinks that all is fine with the current implementation, then there's noting else I can do about this, and this will probably be noticed by the larger community after the final release of 3.7. By then I fear, that the changes needed will not be possible without breaking BC, and we would probably have ended up with a very welcome and very nice addition by @laoneo which is probably crippled by one simple design flaw, which could have been fixed prior to its release.

As for the initial subform field implementation, as you can imagine, it is much easier to link such a field to a specific form (which contains multiple fields) than to multiple fields, where one can also by mistake link to a wrong one.
In the same context it is then also easier and more consistent to save the related form field data into the EAV table (#_fields_values), by not introducing json encoded data for sub forms, but saving the data with additional form id in that table. Remember, form !== context (if category filters might apply).

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 19, 2017

@laoneo not field groups, as a field group is generating a tab in the form.
I am speaking of forms, not form-groups, which can be assigned to different categories of the same context, as I described in my example.

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 19, 2017

@laoneo In my thinking, I would not have the category filter in the field properties, but in the form properties. And I would have a form selection in the field, as in the field belonging to one form. (And the form edit screen would then enable me to order those fields that would have been assigned to the form).

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 19, 2017

@laoneo but it has a lot to do with the issue here, because of how a subform field would be implemented.

Don't get me wrong, I am happy to work on an implementation of this proposal. However, I don't have the time to put that amount of work into a PR that might not get merged. I have put already lots of work in other PRs for Joomla, which are stagnating without having any clue if they will be merged at all.
That is why I am trying to describe the problem and the solution, before I will do work on the solution itself.

@laoneo

This comment has been minimized.

Copy link
Member

laoneo commented Jan 19, 2017

The only thing you are missing in the current code is that you can assign a field group to a category or article. The ordering of the fields is already implemented. You can order them around in the list with drag and drop.

I think I understand where you want to go to. But I would to try to fit in the current scheme. Adding an additional layer where you can assign a field to a form is for me to much of an overhead. Perhaps you should to try to make the field groups more powerful and not adding a new layer of complexity as I guess we have achieved the max for the regular Joomla user already. If you need CCK functionality, then I recommend to use a CCK extension. com_fields should target the user base which do need only some additional fields for entities like users or articles.

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 19, 2017

The ordering of the fields is already implemented. You can order them around in the list with drag and drop.

Yes, the form ordering, as I had described it would not be needed, if a form filter would be applied to the list.

But I would to try to fit in the current scheme. Adding an additional layer where you can assign a field to a form is for me to much of an overhead. Perhaps you should to try to make the field groups more powerful and not adding a new layer of complexity as I guess we have achieved the max for the regular Joomla user already.

I disagree:

  • Since there is an ability to have different context through the use of category filters, the forms should be there to group fields of that context.
  • The field-groups do not provide a definitive solution, as they would
    a) create separate tabs (which might not be wanted)
    b) allow fields to be in multiple groups
  • For paragraph b) of the last point, for clarity, easier management and less errors, a field should normally belong to exactly one form
  • Field Groups are part of "structural" forms and should group fields inside of these. They are not there to group fields in the contexts that might be introduced by different categories of the content. A form (or content type form) would be the correct use for that.
  • Having fields belong to forms (or content types if you wish) is not overhead. It is correct structure and hierarchy...

Perhaps you should to try to make the field groups more powerful and not adding a new layer of complexity as I guess we have achieved the max for the regular Joomla user already.

My concern is that we have not reached the max for the regular Joomla user already
Joomla would benefit from this improvement a lot. And sites are already more complex and will be more complex in future. It would make Joomla a lot more attractive to developers!!!
If there is no absolute need for a full-fledged CCK why not being able to do it correctly with Joomla out of the box? The thing is already there, and it's easier to combine other extensions with Joomla, than with a CCK.

If you need CCK functionality, then I recommend to use a CCK extension. com_fields should target the user base which do need only some additional fields for entities like users or articles.

I disagree with that statement. CCK's bring extra complexity and a as explained above lot of other considerations and support issues into the game. In regards to the issues I raised, I do believe that a CCK would be overkill. Also, the existence of the CCKs (which are fine, but all introduce more complexity) is that such things were not implemented in Joomla, until now.

I find it a pity, that such nice functionality is introduced to Joomla and it is not been made complete...

I also find it a pity that a valid concern is raised, a proper solution is being thought of, and is met by such resistance. Why?
😞

@Bakual

This comment has been minimized.

Copy link
Contributor

Bakual commented Jan 19, 2017

Since there is an ability to have different context through the use of category filters, the forms should be there to group fields of that context.

The context is a hardcoded value from the extension models. Changing that would need a complete rewrite of com_fields. That's likely not something that should be done so short before beta.
Remember it is not meant to be a CCK.

Having fields belong to forms (or content types if you wish) is not overhead. It is correct structure and hierarchy...

Content types in the context of Joomla is exactly the same as we currently have. There is only the content type "article" in com_content. There is no content type "cars" and "planes". So to avoid confusion. Don't use "forms" or "content types" when you refer to different types of the same content type/form (eg articles).
Until now, it wasn't even possible to have them different except for some appearances.
With com_fields you get a little bit of customising but it is explicitely not meant to replace a CCK.

@laoneo

This comment has been minimized.

Copy link
Member

laoneo commented Jan 19, 2017

I find it a pity, that such nice functionality is introduced to Joomla and it is not been made complete...

The project was going for about 9 months, where have you been in that time to help me developing it with your input? com_fields was merged almost three months ago, again you was not there to help. Now you come with such wording to say it is not complete. It was almost a year ago as we started with com_fields and no help from your side. Now you are targeting me say it is incomplete. Sorry but I'm out here, don't have time for such bullshit.

I also find it a pity that a valid concern is raised, a proper solution is being thought of, and is met by such resistance.

I just tried to give you some hints where to start. It was no resistance at all, it should be help. Feel free and make a PR. At the end the community decides what will come in and what not, not me alone.

@frankmayer

This comment has been minimized.

Copy link
Contributor

frankmayer commented Jan 19, 2017

@laoneo I was not criticizing your work. And the "not complete" is not referring to the excellent work you have put in! This is exactly why I hate text chats and prefer real discussions. Please do not get this wrong!!

As for where I have been for nine months... Well, I was sick for about a month, then fell into a coma, luckily survived, then had to do slow for a month, etc, and then I had to deal with the slack that had piled up for 3 months in my business while also doing the day to day work... Sorry I couldn't be there. If I had time to participate more in Joomla, I would have helped you in your efforts. I think you can see, through my recent work, that if I have time, I do help out in whatever capacity I can.
And I do really feel sorry for the misunderstanding, that might have occurred here. That was not my intention.

@joomla-cms-bot

This comment has been minimized.

Copy link

joomla-cms-bot commented Oct 1, 2018

Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/11905

@Quy

This comment has been minimized.

Copy link
Contributor

Quy commented Oct 1, 2018

Please test PR #22446


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/11905.

@stutteringp0et

This comment has been minimized.

Copy link
Contributor

stutteringp0et commented Oct 2, 2018

So, deleting comments regarding 3rd party extensions that achieve this goal is a thing joomla does now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment