Here It is my code:-
======Apex Controller========
public with sharing class AccountController1_picklistrendering { public String account { get; set; } public String selectedAccId{get;set;} public String selectedConId{get;set;} public List<SelectOption> getAccountNames() { List<SelectOption> accOptions= new List<SelectOption>(); accOptions.add( new SelectOption('','--Select--')); for( Account acc : [select Id,name from Account ] ) { accOptions.add( new SelectOption(acc.Id,acc.name)); } return accOptions; } public List<SelectContact> getContactNames() { System.debug('Entered ContactNames account id...........'+selectedAccId ); if(selectContact != null) contact con = [select name from contact where accountid=:selectedAccId ]; return con; } }


=============VF Page==================
<apex:page controller="AccountController1_picklistrendering"> <apex:form > <apex:pageBlock title="Account Name"> Account Names&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <apex:selectList value="{!selectedAccId}" size="1"> <apex:selectOptions value="{!AccountNames}"/> <apex:actionSupport event="onchange" reRender="a"/> </apex:selectList> <br/><br/> Related Contact Names&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <apex:pageBlockTable value="{!ContactNames}" var="items"> <apex:column value="{!items.name}"/> </apex:pageBlockTable> <apex:selectList value="{!selectedConId}" size="1" id="a"> <apex:selectOptions value="{!ContactNames}" /> </apex:selectList> </apex:pageBlock> </apex:form> </apex:page>

Hello members
The question related to marketing cloud ; so right forum to ask?
I want to know difference between data extension and a list.

I know only one answer but there must be several.

In lists, emailadress is mandatory field ; in data extension emailaddress is not mandatory field i.e subscriber ID is mandatory.

Please let me know

thanks
shweta

 

Create an Apex class that returns an array (or list) of strings: 
Create an Apex class that returns an array (or list) of formatted strings ('Test 0', 'Test 1', ...). The length of the array is determined by an integer parameter.The Apex class must be called 'StringArrayTest' and be in the public scope.
The Apex class must have a public static method called 'generateStringArray'.
The 'generateStringArray' method must return an array (or list) of strings. Each string must have a value in the format 'Test n' where n is the index of the current string in the array. The number of returned strings is specified by the integer parameter to the 'generateStringArray' method.

MyApexClass to above Challenge:

public class StringArrayTest {
    
    public static List<string> generateStringArray(Integer n)
    {
        List<String> myArray = new List<String>();
        
        for(Integer i=0;i<n;i++)
        {
            myArray.add('Test'+i);
            System.debug(myArray[i]);
        }
        return myArray;
        
    }

It's compile and execute as per requirement in Developer console. But Traihead showing the below error:

Challenge not yet complete... here's what's wrong: 
Executing the 'generateStringArray' method failed. Either the method does not exist, is not static, or does not return the proper number of strings.

Anyhelp would be greatly appreciated. Thanks.
 

Hi all,

I'm evaluating pros and cons for building an integration with Salesforce on Force.com platform. Since the pros don't need to be commented on, I'll just ask about what some developers consider as cons. I came across this SO question: http://stackoverflow.com/questions/1664503/disadvantages-of-the-force-com-platform What part of this can you confirm as true, and what not? The question is closed because of the format, but it'd be great if someone could provide concrete answers to it (when you google for disadvantages you get this at the top). I'll copy and paste some of the mentioned disadvantages for easier referencing:

1. Apex is a proprietary language. Other than the foce.com Eclipse plugin, there's little to no tooling available such as refactoring, code analysis, etc.
2. Apex was modeled on Java 5, which is considered to be lagging behind other languages, and without tooling (see #1), can be quite cumbersome.
3. Deployment is still fairly manual with lots of gotchas and manual steps. This situation is slowly improving over time, but you'll be disappointed if you're used to having automated deployments.
4. Apex lacks packages/namespaces. All of your classes, interfaces, etc. live in one folder on the server. This makes code much less organized and class/interface names necessarily long to avoid name clashes and to provide context. This is one of my biggest complaints, and I would not freely choose to build on force.com for this reason alone.
5. The "force.com IDE", aka force.com eclipse plugin, is incredibly slow. Saving any file, whether it be a class file, text file, etc., usually takes at least 5 seconds and sometimes up to 30 seconds depending on how many objects, data types, class files, etc. are in your org. Saving is also a blocking action, requiring not only compilation, but a full sync of your local project with the server. Orders of magnitude slower than Java or .NET.
6. The online developer community does not seem very healthy. I've noticed lots of forum posts go unanswered or unsolved. I think this may have something to do with the forum software salesforce.com uses, which seems to suck pretty hard.
7. The data access DSL in Apex leaves a lot to be desired. It's not even remotely competitive with the likes of (N)Hibernate, JPA, etc.
8. Developing an app on Apex/VisualForce is an exercise in governor limits engineering. Easily half of programmer time is spent trying to optimize to avoid the numerous governor limits and other gotchas like visualforce view state limits. It could be argued that if you write efficient code to begin with you won't have this problem, which is true to an extent. However there are many times that you have valid reasons to make more than x queries in a session, or loop through more than x records, etc.
9. The save->compile->run cycle is extremely slow, esp. when it involves zipping and uploading the entire static resource bundle just to do something like test a minor css or javascript change.
10. In general, the pain of a young, fledgling platform without the benefits of it being open source. You have no way to validate and/or fix bugs in the platform. They say to post it to their IdeaExchange. Yeah, good luck with that.
11. You can't package up your app and deliver it to users without significant user intervention and configuration on the part of the administrator of the org.
12. THERE IS NO DEBUGGER! If you want to debug, it's literally debug by system.debug statements. This is probably the biggest problem I've found
13. Even tho the language is java based, it's not java. You can't import any external packages or libraries. Also the base libraries that are available are severely limited so we've found ourselves implementing a bunch of stuff externally and then exposing those bits as services that are called by force.com
14. There is no mention anywhere in even the most deep-dark technical references of the common errors, or even the limitations of a given api or feature