Hi,

When buidling a page you can only see the field LABELS at the left and right window.
I would also like to see the the field NAME somewhere. Because I have multiple Labels that are the same, only the fieldnames differ...

For example:

Product A
width
height

Product B
width
height

Product C
width
height

In the PAGE BUILDER I cannot see which width-field belongs to which Product Label. This is very confusing when adding extra elements (Products) in this example

I don't use products in my component but this is just a way to illustrate my problem

Sorry, I'm a bit confused by your post: What do you mean by:Isn't this a bit more about how you separate/layout your page?

Also, just to clarify as I'm not sure if this is a design 'question' or a feature request for the builder, please provide a screenshot and or a demonstration o what you mean.

Many thanks,

Gez

Hi,

Here's my issue:

When I'm in PAGE creation mode, I cannot see the real fieldnames.

At the blue/purple marking you see the real fieldname. (Within red glowing window I pasted over this screen)
This realname you cannot see when you are creating the PAGE.

And as you can see, I have multiple fields that have the same field LABEL but a different field NAME.
This way I can't put the right field at the right location, because I can't see it's real NAME.

Hope this clarifies my issue

Regards

Hi GC,

Thanks for the screenshot and extra explanation - I fully understand what you mean now!

Unfortunately, this is a convention of COOK at the core and I'm unsure whether or not this would change. I have 3 suggestions (and a question or 2)...

SUGGESTIONS

1. Put in a feature request for either a swap to using fieldnames or a combination of fieldlabel (fieldname) in the New Features section. I know that @admin is incredibly busy expediting the production release of V2.0 so I'm not sure how quickly this would happen even if it was agreed to do so... However, there's nothing to lose by asking
2. A question precedes this suggestion... It looks like you have a lot of repeated data in this table, right? For instance, I see a set of 3 fields that are repeated at least 10 times in that table. Are you always going to be filling in all of those fields for the plaatsing object or will you sometimes only need a few?
   
   The reason I ask is, is because it looks like a massive table and if you will not always require all of those sets of fields for each record, for the sake of data normalisation & performance it would be advisable to extend your tables to include another that stores each of those sets of 3 fields including the plaasting_id as an FK field. This will massively reduce redundancy in your component. In fact, it may well be worth considering anyway.
3. This may not be a favorable approach but, appending an incrementing number to the label as you've done would be possible too. If you want, you can then override this in your layouts by accessing the fields' properties.

Hope this helps!

Gez

Thanks for your quick reply.

I'm still over-thinking which approach to choose...

Your number 2 uses the ajax approach right? Was trying that yesterday, but it's a lot of work. I did it before (without Cook) so I must be able to do it again...

Number 3 might be an option if nr 2 fails

Hi @goslingcools,

No. 3 is definitely the easiest but, that does potentially leave you with a massive table and potentially a lot of redundancy.

N0. 2 doesn't necessarily have to use ajax: Once you have created your other table, in the save function of your plaatsing you could do a redirect to your related form (re-using plaatsing.id) to add the related item. Then you could keep using the save and new option to keep passing in what will then be your FK field (plaatsing_id) to populate itself in the next entry until you hit the save and close. Save and close will by default take you to your plaatsing_related grid that you could easily group by plaatsing_id.

Obviously, in your plaatsing fly, you will want to grab all of the related data which there are a couple of tutorials on here on the forum. This is one of them (solution by @admin) - www.j-cook.pro/forum/9-coding-inside-you...-related-table--item.

Hope it helps!

Gez

I think I understand your explanation of No. 2 well.

But I have 4 different Items to add dynamically to 1 plaatsing. So redirecting would not be very clear I think???

Exiting the 1st related form should than redirect to related form 2, this form should redirect to form 3 on exist, etc.

I'm thinking of writing an external class that controls saving/updateing/deleting of elements from other other tables.

Part of this class will be called in the Save function of Plaatsing
Other part will be called to Fill existing elements for Plaatsing
Other part will generate the JS & HTML that needs to be in the View of Plaatsing for dynamically adding NEW elements

Something like this...

Good idea?

Sure, I understand... If you have multiple related tables then option 2 wouldn't be very intuitive!

You could achieve it as you suggest but I would say that AJAX will be the most user-friendly approach with regards to user interface.

If you've used ajax in a non-cook/joomla way before, you could check out @admin 's how to on implementing ajax that will help out in terms contextualising this in COOK.
*****ADD******
LINK: www.j-cook.pro/forum/7-design-your-appli...sing-the-modelactrlr

Sorry, forgot about the link
******************

Hope it helps!

Gez

Notify of edit previous

G

With ajax I think the saving of each element will work almost the same way as the Cook Builder works, right?

A small save or edit icon next to each element that you dynamically insert? I would need a delete icon as well...

So you save elements with this small save icon, and not with the main Save of the Plaatsing... well, you should do a check if all elements are saved before saving the Plaatsing itself of course.


My idea is to save all elements upon saving the Plaatsing.
I know this is not ideal but I know how to get this done. I think...

The ajax way need's all edit/save/delete functions from the element model. Not sure how to call these all correctly yet...

Sort of - well, in essence yes!

You'd need to update your save/update functions to accommodate saving the related items like:

1. SAVE routine - save the plaatsing item as normal and upon success get it's ID to pass as an FK to all of your related tables & items. Then in the same routine, check if there are related items to save, loop through them all to get the data to save in an array (ideally use serialize for efficiency), call your model for the new items if there are any and save them by calling their save function for each of them. It may be better to create a save routine for saving multiple records in your related model rather than re-calling the same function over and over - just a thought.
   A small save or edit icon next to each element that you dynamically insert? I would need a delete icon as well...
   this won't work for new plaatsing items as you won't have plaatsing.id yet to use as FK. Obviously, once you have saved the main item, you could render the buttons yu require...
2. UPDATE routine - obviously, in this case, you need to grab the related data into the form. There are a couple of things to consider here.... Do you want to be able to edit the data straight off? How to detect changes etc. Personally, I would lock the related fields on loading an existing plaatsing and maybe provide an 'edit' button that changes the class of the field to 'updated' or something. Then, using jQuery, provide a save button for it and switch the class back to 'normal'. Also, in your main plaatsing item, you will want to see if there are any related fields with the 'update' class and pass them to a function in their model to loop through them and update the relevant record.

Obviously, delete actions will work as save for individual related items. Remember to be careful how you set the integrity of foreign fields in the builder... For instance, if you want to delete a plaatsing item, do you want to delete all related records? Again, this is something you could handle with prompts and options in jQuery dialogs or something if you want to.

Hope this helps!

Gez

Thanks again,

I noticed that the in save($data) when I print_r($data) it contains only the plaatsings fields not the extra elements fields.
However grabbing the $_Post does get all fields from the form, also my element fields.

However(2), when using an ajax call to get the element fields displayed into the form they are named like jform[overwerk].

While when I use field names like overwerk[], I can grab them easier from the $_Post than multiple fields like jform[overwerk]. Or am I thinking wrong?

The save routine I think I have figured out.
- delete all elements that are not in the formdata (el id's) and have the plaatsings ID,
- update elements that are in the formdata (with el id)
- insert new elements that are new (no el id) in the formdata

goslingcools wrote: What exactly do you mean by "extra elements fields"? Are these the related items - I mean sub items of plaatsings?
goslingcools wrote: If your anwer to my first question is yes, then in relation to the second half of your post (above), the reason you get different data in the $_POST & data is that data in the jform[overwerk] is only that specified in your forms XML - i.e. your plaatsings table.

Personally, I would let jForm validate the plaatsings item with jform[overwerk] and call all your other data by adding additional evaluation in the save function. This way, you ensure ABSOLUTELY that jform validates the data. As for the rest of your related fields, just grab them using jQuery in the on submit and do any processing there. Again, this way, if you're posting them to a custom save routine in their model, you'll be sure to be validating everything correctly.

Does that make sense?

Hope it helps and I understood your question properly...

Gez

don't forget to check token as per linked post from earlier in the thread! This will prevent direct posting to the form!

G

The overwerk[] field is a subitem yes.
Of couse the plaatsing's own fields are saved like jform[title] etc. with the normal save routine. I won't touch these.

What I meant is, when using ajax to retrieve the sub element form fields to display them in the plaatsings form, they get this format:
jform[subitem-title], jform[subitem-color]

while I need them to be:

subitem-title[], subitem-color[],

in order to have multieple subitems in the form that I can catch with $_Post

Multiple fields like this in the plaatsings form
subitem-title[], subitem-color[]
subitem-title[], subitem-color[]
subitem-title[], subitem-color[]


Haha, hope I'm a little more clear...