function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
indranily81indranily81 

Is there any other way to send the value of <apex:inputText> field value

Hi,

 

Is there any other way to send the value of <apex:inputText> field value to the controller or extension other

than setting a private member variable in the controller/extension ? 

 

e.g.

if a VF code is like

<apex:inputText id="find"  value="{!findvalue}"/>

then a corresponding setter method is needed in controller/extension as setFindvalue() and the

member variable is set there.

 

Is there any other route to send this  to the controlle/extension to process ?

 

Thanks

indranily81

WesNolte__cWesNolte__c

Hey

 

First I'd like to ask why? Do you have a use in mind? If you could give a specific example I could help you.. as it stands you either need a 'setter' method or a public property, which in your case would be,

 

public String findvalue{get;set;}

 

Cheers,

Wes

indranily81indranily81

Many thanks wez for the reply.

 

Actually if I have a VF page containing 50 input text box then as per the doc i need to set 50 attributes.

i was thinking if there is any other way around so that only setting up the attributes can be avoided. Like in

java as we can use request.getparameter('id').  

bob_buzzardbob_buzzard

You could set up a list of Strings and use the textboxes within a repeat component, each textbox would then be backed by a String instance from the list.  It would then be up to your controller to manage the initial population and later processing of the list. 

bob_buzzardbob_buzzard
Actually, you might need to have a list of StringWrapper type objects, each of which simply wraps a String and provides a getter/setter, so that the appropriate methods are available to the page.
WesNolte__cWesNolte__c

Yip, Bob's method would work.

 

You can also fetch the parameters like you have proposed but it would be a bit hackey and you'd have to figure out what the parm names are. I'm also from Java background, welcome to Force.com:)

 

Wes

bob_buzzardbob_buzzard
Me too on the Java background - single rather than double quotes for Strings is the biggest hurdle I've found :)
indranily81indranily81

keeping in tone with bob I miss the need of a debugger :). even a small trigger code needs to be tested through a

test class. It's painful.

WesNolte__cWesNolte__c

The 'system.debug' logger does help, although it's a bit verbose at times. I've tried to develop debuggers for the platform in a number of ways.. writing to the DB cannot really be done since DML isn't possible in getter, setters or constructors and writing to an offsite log via webservices isn't really viable because of their asynchronous nature:(

 

Wes

indranily81indranily81

Since the execution of the code is on the server side, I guess there is little scope for changing a state of a variable at

runtime like in 'watch' mode of a debugger. System.debug is I guess just a log4j output. Correct me if I am wrong.

WesNolte__cWesNolte__c
Yeah that would be my guess too. Would be nice if the wrapper was a bit richer..