subforms where introduced in Joomla 3.6, selecting from the list of available field types should include a repeater or subform like choice
There is no subform
Category | ⇒ | Fields |
Labels |
Added:
?
|
Title |
|
Title |
|
||||||
Labels |
Removed:
?
|
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
For the editing part it would work. But how do you display then the data on the front?
I suppose by processing the json through php
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 go for it.
@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:
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.
(extension) -> categories -> fields
It's more like extension -> context (basically equates to a form) -> field group (fieldset / tabs) -> fields
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.
Hmm, so the context would then for example be com_content.article
? (Will look at that PR in a bit)
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.
But still, you're missing the categories, which play a role, too.
Categories aren't used in com_fields.
com_fields is not generating any file. Just to be clear on that point.
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.
@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.
(@laoneo while writing this new comment I saw your last one. Maybe this will explain thing 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.
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.
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
So what you want is to assign field groups to categories or articles. But I guess this has nothing todo with this issue here?
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 safe 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).
@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).
@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.
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.
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:
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.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?
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.
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.
@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.
Category | Fields | ⇒ | com_fields Feature Request Fields |
Priority | Medium | ⇒ | Low |
Status | New | ⇒ | Discussion |
Labels |
Added:
J3 Issue
|
Status | Discussion | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-10-01 22:52:45 |
Closed_By | ⇒ | Quy |
Closed_By | Quy | ⇒ | joomla-cms-bot |
Please test PR #22446
Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/11905
So, deleting comments regarding 3rd party extensions that achieve this goal is a thing joomla does now?
This would mean you can select a XML file then which contains the subform?