so I have a form that I'm using for new items, and to edit items.
The input fields therefore may have a value or not. I'm using this code in the value field.
<input name="uuid" value="<cfif isNull(item.GetUuid())>#item.GetUuid()#</cfif>"/>
Is this the best way to do it? I would have thought the ORM returning a blank object or something maybe cleaner, but not sure of a tider way to do it?
This might work
<cfproperty name="uuid" default="">
Related
Am using EclipseLink 2.4.2 with derby database. I have an Entity class which has a String array. Now, i need to map this array to a separate table 'MY_ARGS' such that index must be mapped to one column 'ARRAY_INDEX' and the value (at index) must be mapped to another column 'ARG'.
In hibernate we have 'array' element through which we can do this. Like below :
<array name="args" table="MY_ARGS" cascade="all">
<key column="PARENT_ID"/>
<list-index column="ARRAY_INDEX" />
<element type="string" column="ARG" length="16384" />
</array>
But in eclipse-link am not able to find any such element (am using eclipselink-orm.xml) through which i can achieve this!
Does Eclipselink support such array to table(multi-column) mapping?
I read about #Converter through which we can convert the data type while storing to/retrieving from DB. But it looks like converter deals with single column and cannot store to two columns simultaneously.
Is there a way that i can do this through converter or any such work around? (I prefer not to use collections)
Any quick help is greatly appreciated!
Thanks in Advance!
-Alekhya
I have an ODS, which is bound to an ADO.NET datatable. There is one select parameter. I would like to use a public property which I have declared in my code-behind as the select parameter, something like:
<SelectParameters>
<asp:ControlParameter ControlID='<%# EInfoProperty %>' Name="quote_header_id"
PropertyName="headerId" Type="Int32" />
</SelectParameters>
The above syntax doesn't work, and I've been unable to find anything here, on MSDN or on Google that might help here. Is there a way to do this, or am I stuck sticking the value in the Session, or something?
From everything I could find, this is not currently possible. For my purposes, I ended up putting the value in question in the session and using a SessionParameter.
I am encountering a requirement where I need to use multiple hidden field elements. The values for these elements are stored in an array. What would be the best possible approach to build that in the zend form.
id[] = array('1', '2', '3', ....);
This values for id[] is dynamically generated.
And the html part for my case would look something like this
<input type="hidden" name="ids[]" value="id[0]" />
<input type="hidden" name="ids[]" value="id[1]" />
<input type="hidden" name="ids[]" value="id[2]" />
.
.
.
and so on.
How can a create multiple input hidden field elements, which I later want to use it in my controller by using the populate method.
In case if anyone has an idea how to approach this, would be really helpful.
P.S. Im using Zend Framework 2
It sounds like you're running into a use-case anticipated by Form Collections.
\Zend\Form has baked in support for managing this kind of relational structure.
The gist of it is that you create a Fieldset which can hold a collection of identifiers for your related entity.
While the documentation doesn't demonstrate with hidden elements, there's no reason you can't create a fieldset full of hidden elements. Take a careful look at the "Category" fieldset in the documentation.
I'm creating a reusable workflow in SharePoint designer 2010. I've created a custom content type with all the necessary fields that I'll be used in the workflow. But I'm not able to get the Modified By field (Editor) inside the workflow.
<FieldRef ID="{d31655d1-1d5b-4511-95a1-7a09e9b75bf2}" ReadOnly="TRUE" Name="Editor" DisplayName="Last Updated By" FromBaseType="TRUE" Required="FALSE" PITarget="" PrimaryPITarget="" PIAttribute="" PrimaryPIAttribute="" Aggregation="" Node="" />
I really doubt whether the ID is matching with the inbuilt editor field. How can I cross-verify this? Any ideas?
Not sure but do you really need to include it explicitly? Editor is part of base content type : Item, and down the hierarchy all other content types should be inheriting it without the need to explicitly include it.
Regards,
Nitin Rastogi
A set of forms (using Zend_Form) that I have been working on were causing me some headaches trying to figure out what was wrong with my XML configuration, as I kept getting unexpected HTML output for a particular INPUT element. It was supposed to be getting a default value, but nothing appeared.
It appears that the following 2 pieces of XML are not equal when used to instantiate Zend_Form:
Snippet #1:
<form>
<elements>
<test type="hidden">
<options ignore="true" value="foo"/>
</test>
</elements>
</form>
Snippet #2:
<form>
<elements>
<test type="hidden">
<options ignore="true">
<value>foo</value>
</options>
</test>
</elements>
</form>
The type of the element doesn't appear to make a difference, so it doesn't appear to be related to hidden fields.
Is this expected or not?
As it was rather quiet on here, I took a look further into the source code and documentation.
On line 259 of Zend_Config_Xml, the SimpleXMLElement object attributes are converted to a string, resulting in:
options Object of: SimpleXMLElement
#attributes Array [2]
label (string:7) I can't see this because
value (string:21) something happens to this
becoming
options (string:21) something happens to this
So, I hunted through the documentation only to find that "value" is a reserved keyword when used as an attribute in an XML file that is loaded into Zend_Config_Xml:
Example #2 Using Tag Attributes in Zend_Config_Xml
"..Zend_Config_Xml also supports two
additional ways of defining nodes in
the configuration. Both make use of
attributes. Since the extends and the
value attributes are reserved keywords
(the latter one by the second way of
using attributes), they may not be
used..."
Thus, it would appear to be "expected" according to the documentation.
I'm not entirely happy that this is a good idea though, considering "value" is an attribute of form elements.
Don't worry about this. The reserved keywords were moved to their own namespace, and the previous attributes were depricated. In Zend Framework 2.0 the non-namespaced attributes will be removed so you can use them again.