Create element without db column?

[greif]

Hi, is it possible to have elements in the form without having to have a db column for them? Ie., in my custom register form I have captcha plugin, but I don't need to have the captcha saved to db.... The same goes for some text fields, which are used for calculations purposes, without their own db columns... ?

 

[cheesegrits]

Our element model does have a recordInDatabase() method, and a getFieldDescription() method, but those aren't "configurable". Either the element plugin is coded to recordInDatabase(), using the field type specified by getFieldDecription(), or it isn't.

So for instance, the "button" and "display" element plugins do not create a field in the table, and don't save anything.

I can't recall why I decided to have the CAPTCHA element plugin record results in the database. I do remember there being some valid reason at the time, though.

Anyway, you're pretty much stuck with it working the way it does. If having those extra fields actually becomes a problem, as far as MySQL resources goes, let us know. But for now, just ignore that data. I doubt very much it has any effect at all on your overall app performance or server resources.

-- hugh

 

[greif]

Hi hugh,
that's what I thought. But, as I would like to use fabrik as front-end solution, I would like to keep my database design clean - I mean, it's not a show stopper to have the columns in db, but it makes life much harder. Ie., ability to create form with fields, that are used for calculations only, seems like kind of basic requirement in any bussines app. Yes, it is possible somehow to have a column for each of the fields, but it's not clean solution...
Would be great to have an option to not create column for the element, and use it for display/input only....

 

[cheesegrits]

I'm not entirely sure how it makes things "much harder". Either way, you still need to create an element on form. It's just a question of whether that element stores un-needed data in the table or not, which doesn't really make anything harder / easier.

You could look at using the 'display' element, which is essentially just a div, that your JS could set the content of on the fly.

-- hugh

 

[greif]

I'm not entirely sure how it makes things "much harder".

Well, it creates mess in your database.
Let's say you want to add two fields to your form, that are used for input and update data in another table. You add two field elements, which create two unnecesarry db columns. After some time you come back to your db, and you probably won't have any idea why the columns are there.
Or, you have dbjoin element in your form to update form data based on your selection. You don't really need/want the data to be stored.
Or, you want to create custom form, where all the fields are used for calc only, and only the total column should be saved. You really don't want to have a table full of unnecesary data..

Would be really usefull to have a switch to store/not store , create/not create db column. Without that it's almost impossible to keep your db design clean. It would also free your hands for creating custom forms..

 

[rob]

its not something I am keen on implemeting - it produces more logic in our code for what is in my oppinion a very minimal benefit.

 

[greif]

Thanks for letting me know... Would it be possible for you to create a field element "version", that would not create db column or save anything and would be used for input only, so the input can be accessed by php plugin? That would solve most of my problems and would make creating custom forms much easier...

 

[sgorney]

Just throwing this idea out there - greif, would it be possible for you to create plugin elements that don't use a DB Column on your own?

Take a look at the display element type, for example:
(plugins/fabrik_elements/display/display.php)

class plgFabrik_ElementDisplay extends plgFabrik_Element
{

	protected  $fieldDesc = 'TEXT';

	function setIsRecordedInDatabase()
	{
		$this->_recordInDatabase = false;
	}

	function getLabel($repeatCounter = 0, $tmpl = '')
	{
	
	}

function render($data, $repeatCounter = 0)
	{
		$params = $this->getParams();
		$id = $this->getHTMLId($repeatCounter);
		$value =  $params->get('display_showlabel', true) ? $this->getValue($data, $repeatCounter) : '';
		return '<div class="fabrikSubElementContainer" id="'.$id.'">'.$value.'</div>';
	}

if you just duplicated that element, hacked up the XML some and changed the php a little and modified the render function, you could potentially do what you're trying to do - right? Just have the render function return some HTML that displays your form elements, but leave the recordInDatabase set to false.

Would this work?

 

[greif]

Hi, thanks, yes, that would work for sure, I already looked at the code before, but I don't have enough php/joomla framework knowledge to be able to mix the display and field elements together..:-(

 

[cheesegrits]

I'm with Rob. I really don't see enough benefit, for something that would complicate some already complex code.

Apart from "mess" in the database, I just don't see how implementing options to the textarea and/or field elements to optionally turn off database usage would make creating custom forms any easier. And it would involve quite a lot of changes and special case handling in the code for those elements.

Any 'mess' in the database could be solved with a simple PHP cron plugin that just does

UPDATE yourtable SET foo='unused'

... once a day. Or some other informational message in case you forget what the field was for.

-- hugh

 

[greif]

Apart from "mess" in the database, I just don't see how implementing options to the textarea and/or field elements to optionally turn off database usage would make creating custom forms any easier. And it would involve quite a lot of changes and special case handling in the code for those elements.

I completely understand that adding an option to not create db field would be too much hassle for what it brings. Would it be possible for you to create a field element "variation", that would be hardcoded to not create db field, so it could be used as input only field on the form? I suppose/hope that would not be that difficult, but I don't have enough joomla/php knowledge to do that myself...
Thanks

 

[cheesegrits]

Anything is possible. But probable, and within a given timetable? That typically depends on whether / how much someone is paying me to do it or not.

-- hugh

 

[sdavies68]

A question?

Is it as simple as setting the recordInDatabase = false;

for the plugin?

I ask, because I use calc element (particularly the ajax update) to display a field from another table dependant on what is changed in one of the forms elements. I dont want to store this in the table (its already in another table). In effect I just want a display, but the display element is not ajax enabled.

So I suppose can we get an ajax enabled display element which works like the calc but does not save to the database.

 

[cheesegrits]

Yes and no.

There were some lurking issues with the _recordInDatabase setting which I haven't rooted out yet, to do with changing that setting once an element is created. When I get some time, I'll thrash them out.

In other words, it's OK if that is set to false in the plugin's model code, so it's false when the element is created. the problems seem to happen if you then change that to false after an element has been created with it set to true (or vice versa).

I've just never dug in to the issue because it's not something we ever do. I was just trying it, last time this whole discussion about having 'record in database' available as a per-element setting was raised.

-- hugh

 

[Mezhuev]

Why display element creates DB column then???