are there better fields naming convention?

[clsource]

Hello, 

I always put some kind of prefix to fields

like some user fields

usrFirstName

usrLastName

but I would like to name them more like

firstName

lastName

so when using a page like this

$user = $pages->get('/users/clsource');

I can do this

$user->firstName

and not this (more ugly way)

$user->usrFirstName

Yes I know this is already possible, 

but when you handle a lot of fields, some fields collide with the same name but with different output and format.

Is there a way to make a namespace or something,  

so using prefixes is no longer necessary?

In PW you can organize fields inside categories, 

could be that I can have multiple fields with the same name,

but whitin different categories.

and see them sorted inside the template field selector by categories?

Thanks!.

[clsource]

I think I found a temporary solution.

I wish there was someway to sort field selection in templates using categories.

The solution is the following

create a models directory in /templates/

prefix fields as normal

For example an user

usrFirstName

a model named /models/User.php

that wraps all the user related data

<?php
class User {

public $firstname;
public $page;

public function __construct($user) {
    // fill the vars
    $this->firstname = $user->usrFirstName;
    $this->page = $user;
}

// finds a specific user and creates a new User Object
public static function get($id) {
   $userPage = wire('pages')->get("/users/$id");
   
   $user = NullPage;

   if(!($userPage instanceOf NullPage))
       $user = new User($userPage);

   return $user;
}



}

Now you can have pretty property names like

$user = User::get('clsource');

echo $user->firstname;

[apeisa]

Why on earth you want to do that? Why not just call you field firstname?

[clsource]

Why on earth you want to do that? Why not just call you field firstname?

Yes I know that is possible .

But I find using prefixes for field naming a bit awkward.

I usually work with many fields, and since PW currently does not have a field selector that can sort by categories

I have to rely on prefixes, so I can use the right field for the template.

[adrian]

I wonder if the Add Field dialog on the templates page could be enhanced to use the field's tags as optgroup dividers in the select field. I can see that might be useful if you have a lot of fields.

[SiNNuT]

I wonder if the Add Field dialog on the templates page could be enhanced to use the field's tags as optgroup dividers in the select field. I can see that might be useful if you have a lot of fields.

That could indeed be a nice addition and seems to be, at least in part, what TS is after.

The other stuff, some form of namespacing fields, i don't quite understand.

[clsource]

That could indeed be a nice addition and seems to be, at least in part, what TS is after.

The other stuff, some form of namespacing fields, i don't quite understand.

I said namespacing fields to refeer having 2 fields with the same name

but different input/output formatting.

I think this could be a corner use case.

But can reduce the need for prefixes and if you use tags (categories), 

probably it will increase user experience.

[Soma]

I reuse fields as much as possible and try to avoid having too many fields. I have a "firstname" field that could be used on different templates. I don't prefix fields. PW is designed to reuse fields. 

I wonder how many fields you have and why you need to prefix them. I think people tend to create new fields for every template and context, which could lead to 100s of fields. Remember there's template context for fields in PW, you can customize labels and some setting from within the template if you click on a field name.

[clsource]

I reuse fields as much as possible and try to avoid having too many fields. I have a "firstname" field that could be used on different templates. I don't prefix fields. PW is designed to reuse fields. 

I wonder how many fields you have and why you need to prefix them. I think people tend to create new fields for every template and context, which could lead to 100s of fields. Remember there's template context for fields in PW, you can customize labels and some setting from within the template if you click on a field name.

Thats something I wasnt aware of.

It will shrink the fields counter a lot, beause I was using them the way you said described.

A field for each template so they had different input messages and labels.

Thanks

[kongondo]

I reuse fields as much as possible and try to avoid having too many fields. I have a "firstname" field that could be used on different templates. I don't prefix fields. PW is designed to reuse fields. 

I wonder how many fields you have and why you need to prefix them. I think people tend to create new fields for every template and context, which could lead to 100s of fields. Remember there's template context for fields in PW, you can customize labels and some setting from within the template if you click on a field name.

This needs to go on a tut somewhere then

[SiNNuT]

I get the feeling that the field contexts are something that is easily missed but very useful to know. Once you make use of contexts you can also see and edit the different ones from the field page.

[clsource]

@SiNNut

Thanks for pointing that out.

Where can I find more info about field contexts?

thanks

[SiNNuT]

There's not an an awful lot to it (i think), but just a handy feature allowing to change certain settings for a field on a per template basis. It is indeed something that helps to reduce the amount a fields you create.

A google search 'site:processwire.com/talk field context' will reveal some additional info.

[Ivan Gretsky]

I wish we could choose Inputfield types on a per template basis and all the other advanced options. This could reduce the number of fields needed drastically. Not sure it is possible though or if it would slow down the system.

[davo]

I reuse fields as much as possible and try to avoid having too many fields. I have a "firstname" field that could be used on different templates. I don't prefix fields. PW is designed to reuse fields. 

I wonder how many fields you have and why you need to prefix them. I think people tend to create new fields for every template and context, which could lead to 100s of fields. Remember there's template context for fields in PW, you can customize labels and some setting from within the template if you click on a field name.

Occasionally though I struggle when I edit a page and want to access the field from the api but can't remember what I called it. So I have to edit the page, look up the template, work out what fields are in the template and then work out what the proper name for the field is. Unless I've missed something?

[adrian]

Occasionally though I struggle when I edit a page and want to access the field from the api but can't remember what I called it. So I have to edit the page, look up the template, work out what fields are in the template and then work out what the proper name for the field is. Unless I've missed something? 

This is incredibly rough, but throw this at the end of your main.php/main.inc/foot.inc or whatever you are using:

if($user->isSuperuser()){
    $fieldinfo = '<hr /><p>Field details for ' . $page->template . ' template</p>';
    $fieldinfo .= '<table><th>Name</th><th>Label</th><th>Type</th>';
    foreach($page->fields as $field){
       $fieldinfo .= '<tr><td><a href="'.$config->urls->admin.'setup/field/edit?id='.$field->id.'" target="_blank">'.$field->name.'</a></td><td>'.$field->label.'</td><td>'.$field->type.'</td></tr>';
}
    $fieldinfo .= '</table>';
    echo $fieldinfo;
}

This will give you a table of fields for the current template including name, label, and type. The name cell links to the edit page for the field if you need more info. I am actually thinking it make be nice to add the popup of field settings the way soma did it in https://github.com/somatonic/HelperFieldLinks which is a module you should definitely install by the way