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
mmixmmix 

Cancel s-control obsoletion

I noticed that you plan to obsolete s-controls come end of this year. I would like to recommend that you do not obsolete s-controls until you bring apex/VF into the same functional bracket and allow us some time to convert our existing s-controls into VF/Apex.

 

As things stand now, Apex classes do not cover the full API avaliable to s-controls (for example, describeLayout, dependant picklists discovery, picklists for record types, and other web services API calls) and if you obsolete them you will prevent us from maintaining existing codebase and replacing them with newVF ones without offering functional alternative solution, which I assure you is very serious. At the minimum EVERYTHING that is currently available to s-controls has to be present in apex, you could freeze further development of s-control API but you cannot expect us to obsolete our business processes. If we need API calls then we need API calls, and if Apex does not provide them we are forced to stick to s-controls. 

mtbclimbermtbclimber

Moved to the scontrol board.

 

You can use the ajax toolkit from a Visualforce page which gives you full API access.  Obviously we would prefer to have a single programming model for Visualforce but we consider moving away from Scontrols now more important than having a single unified programming model for Visualforce.  I encourage you to only use the Ajax Toolkit for those verbs that are not accessible in Apex today. 

 

BTW, are you really calling describelayout in an scontrol now?

mmixmmix

Yes, I actually MUST call describeLayout but not to discover the page layout (yes I know it sounds silly). For some reason that is beyond my comprehension you have placed a schema metadata information inside the visual layout. The describeLayout is the ONLY way to get picklistsForRecordType property which tells me which picklist items are available for which record type (because not everything is available for every record type) and is also the only way to get validFor() method which gives me the dependant picklist mapping, all of which I need so I can create a List<SelectOption> instances for our wizards and forms. 

 

None of these things are available from Apex, even though they belong there with the rest of the schema information inside describeSObject. 

 

If I am forced to use ajax toolkit from VF page then the VF page is NOT a VF page, its an S-Control embeded in the <apex:page> tag, and you know that. I would have to invoke the API from javascript, forfeit the <apex:*> controls and manually build the <OPTION> tags inside a manual <SELECT> html element and then build an elaborate javascript engine to sync this control with the controller. And why? Because you are rushing to obsolete something without offering a relief. While I respect your desire to move away from ugly stateless S-Controls, that does not give you the free pass to cut out the things you don't fancy, there are people whose daily operations depend on this, the people who pay you tons of cash which constitutes part of your salary, so lets start being professional and serious about this. Heck, I too REALLY WANT to move away from s-controls and convert ALL of our s-controls into VF pages, but you are not allowing me to do that; so the least you COULD DO is allow me to maintain the code that WORKS. You know, so we can earn money so we can pay you, achieve the famous ROI you keep advertising. 

 

And this topic belongs in the VF forum, this is not an s-control problem (s-controls HAVE this functionality), this is a VF problem because VF/Apex DO NOT have this functionality. So this should be read by sf developers, moderators, product managers and all other people working on VF/Apex platform so they would do something about this. Just wishing the s-controls dissapear should not be enough. 

 

mtbclimbermtbclimber

mmix wrote:

Yes, I actually MUST call describeLayout but not to discover the page layout (yes I know it sounds silly). For some reason that is beyond my comprehension you have placed a schema metadata information inside the visual layout. The describeLayout is the ONLY way to get picklistsForRecordType property which tells me which picklist items are available for which record type (because not everything is available for every record type) and is also the only way to get validFor() method which gives me the dependant picklist mapping, all of which I need so I can create a List<SelectOption> instances for our wizards and forms. 

 

None of these things are available from Apex, even though they belong there with the rest of the schema information inside describeSObject. 


 

Would you need it in Apex if inputField respected record type constriction of picklist values?  How are you presenting the options and do you need to do any manipulation on them?

 


mmix wrote:

I would have to invoke the API from javascript, forfeit the <apex:*> controls and manually build the <OPTION> tags inside a manual <SELECT> html element and then build an elaborate javascript engine to sync this control with the controller. And why? Because you are rushing to obsolete something without offering a relief.

 


 

No, you have relief - you can call the api with the ajax toolkit from a Visualforce page just like you are doing.  Is it really *that* inconvenient to add an <apex:page> tag to your scontrol and save it under pages in setup?  At least from within that new structure you have the opportunity to leverage the rest of the powerful things in Visualforce - static resources, custom labels, standard controllers, stateful programming model to name a few.

 

You can mix and match on the client by using apex:inputHidden in conjunction with your html-based picklist. You could even generate a custom component for this though you probably want some synchronization across components to prevent n-describe calls to the same object.

 

FWIW, and you may already be aware but, describelayout can be extremely heavy.  You should, whenever possible, be doing the call with one recordtypeid to minimize the size of the response. You may be doing this already but I thought I'd mention it.

 


mmix wrote:

 While I respect your desire to move away from ugly stateless S-Controls, that does not give you the free pass to cut out the things you don't fancy, there are people whose daily operations depend on this, the people who pay you tons of cash which constitutes part of your salary, so lets start being professional and serious about this. Heck, I too REALLY WANT to move away from s-controls and convert ALL of our s-controls into VF pages, but you are not allowing me to do that; so the least you COULD DO is allow me to maintain the code that WORKS. You know, so we can earn money so we can pay you, achieve the famous ROI you keep advertising.

 


 

Perhaps you don't understand the de-support plan. We have taken no action yet, just initiated a warning. We are planning to put an end to *new* scontrols. Existing ones will remain unaffected, i.e. they will still run and you can still maintain them, i.e. update them.  No one is demanding that you to convert your existing scontrols. 

 


mmix wrote:
 

And this topic belongs in the VF forum, this is not an s-control problem (s-controls HAVE this functionality), this is a VF problem because VF/Apex DO NOT have this functionality. So this should be read by sf developers, moderators, product managers and all other people working on VF/Apex platform so they would do something about this. Just wishing the s-controls dissapear should not be enough. 

 


 

No it doesn't - this is a discussion about the de-support plan for scontrols which is directly germane to this community.  Limitations of Visualforce / Apex that cause you to need direct API access are important to those communities as well but the highest affiinity for this discussion is within the category it now sits.

 

The proper way to communicate gaps is 1) the idea exchange and 2) through your sales rep (telling your rep the idea that's important to you will help him/her work with the product manager to prioritize).  

 

Think about what you most want before you post an idea. If what you most want is to keep developing scontrols then vote on that idea.  If you would prefer that we focus our investment in improving  Visualforce and Apex then log an idea about what you'd like to see done there, e.g. adding record type awareness to inputField, adding picklist information to RecordTypeInfo,DescribeFieldResult based on record type, etc.  I don't think there are ideas yet for these but it's always a good practice to search a bit first before creating a new one.

 

BTW, adding record type awareness to inputField is on our roadmap and we hope to get it out fairly soon but would still appreciate the idea being logged by you if that's a viable solution to your challenge or if you would otherwise benefit from it.

 

Thanks,

 

mmixmmix

Ok, let me see if I understood your proposed solution correctly:

 

1. I send an apex page to client's browser

2. Client uses JS/ajax to load picklists metadata from SF into browser memory

3. I do an ajax (actionFunction) call from javascript to send the same information BACK to SF, to my controller

4. I use the information to generate List<T> structure that I need

5. I rerender the apex:* control on the client by sending the metadata information for the THIRD time down the pipe. 

 

Am I the only one seeing something wrong with this? Why not just have:

 

1. Load metadata from Apex class, generate List<T> and send to client browser? 

 

 

 

To answer your other questions:

 

It is great that you are adding recType sensitivity to inputField, but inputField is not the only VF control. To make user interaction fast and streamlined we often deviate from factory suggested control and maybe show a set of radio buttons instead of a drop down list. I really would like for someone to give me any concrete and meaningfull reason why you refuse to add picklistsForRecordType and validFor into existing Apex describeSObjectResult infrastructure (where it actually belongs as a metadata info). You already have the server side code (you use it to feed ajax) you just need to add few properties to already established classes. Its a one man one hour job to return a Map<T1, T2> (plus secondary work on test and documentation) and you are resisiting it like it will collapse the entire SF. That is what I do not understand.

 

You say that I need to better formulate my request. So here is one very very simple: "We need ability to maintain and expand on business processes", all the branches of this discussion stem from this requirment. One example, a client I am contracting for now has a set of complex case managment processes, and for instance it has a complex 'New Case Wizard' that is comprised of 14 (fourteen) s-controls. Maintaining this business process is not just editing the existing s-controls, it is adding a new case record type and adding few new s-controls to form a new wizard branch. On top of it all we emulate the SF look-and-feel as part of requirments so each time there is a new SF release we have to do a complete Q&A to see if something broke visually, a problem that VF solves automatically. When you introduced VF/Apex you told my clients its the next best thing that will make their life easier and their code faster and then you reaffirmed that position by advertising the obsoletion of s-controls. The result? I constantly get asked when we will "upgrade" their wizard from s-controls to Apex/VF and how can we do that when your proposed 'relief' is slower than current s-control version. They do not want to embedd s-controls in page tags, they want to achieve durable L&F through apex:* controls, the whole works, the pageBlocks, the sections, the editors, etc, etc. We are not married to s-controls, we HATE them, but if API's are not compatible then we have no ALTERNATIVE but to stick with s-controls.

 

And that is what everyone was led to believe, that VF is the "upgrade" of s-controls, the better and improved version that will save everyone from tedious emulation of L&F and allow faster software through server side DML/schema processing. Now ask around in software industry, there is one golden rule when you upgrade any publicly facing API/framework, you maintain functional BACKWARD COMPATIBILITY, you can rearrange things but you do not just DROP a functionality without alternative. And you maintain this compatibility without being asked for it or even worse without forcing your customer to subject such notion to popularity contest on idea exchange; you opened the pandora's box by creating the API, now live up to it. You want to obsolete displayLayout, fine, but get that functionality in other Apex classes, please? Otherwise, how is this any different than an ISV holding my client hostage with upgrades to off-the-shelf software package?

 

Imagine Sun releasing new Java update without java.io package? Just gone, all the classes from the package just not present any more, Sun decided people don't need it. You used java.io? Well, s**ks to be you, Sun live update is still going to update all the workstations and break your software, deal with it... That is the message you are sending with Apex and describeLayout...

mtbclimbermtbclimber

mmix wrote:

Ok, let me see if I understood your proposed solution correctly:

 

1. I send an apex page to client's browser

2. Client uses JS/ajax to load picklists metadata from SF into browser memory

3. I do an ajax (actionFunction) call from javascript to send the same information BACK to SF, to my controller

4. I use the information to generate List<T> structure that I need

5. I rerender the apex:* control on the client by sending the metadata information for the THIRD time down the pipe. 

 


I suppose that's one way to do it but that's not what I was suggesting. My suggestion was more along the lines of:

 

1. I send an apex page to client's browser

2. Client uses JS/ajax to load picklists metadata from SF into browser memory

3. Use client side script to apply the value chosen by the user to an apex:inputHidden element bound to the sobject field in your controller

4. User submits value using normal Visualforce techniques, e.g. commandbutton bound to save method

 

Is this an optimal solution? No, certainly it would be better if you could avoid the round trip in #2

 

Is it more efficient than scontrols? If this is the only processing, no. If there are additional roundtrips in the scontrol that can happen before 1 above in the Visualforce page controller then yes.

 

Is it less efficient than scontrols? No.

 


mmix wrote: 

 

To answer your other questions:

 

It is great that you are adding recType sensitivity to inputField, but inputField is not the only VF control. To make user interaction fast and streamlined we often deviate from factory suggested control and maybe show a set of radio buttons instead of a drop down list. I really would like for someone to give me any concrete and meaningfull reason why you refuse to add picklistsForRecordType and validFor into existing Apex describeSObjectResult infrastructure (where it actually belongs as a metadata info).


 

 No one is refusing to add this metadata to Apex describe functionality.  In a perfect world every API verb would be exposed in Apex but these things take time, sit along side other Apex initiatives and are prioritized accordingly. For prioritization we leverage the ideaexchange for aggregating the ideas that have the most impact as one important input to the process which is why I recommended you go that route. That was not an expression of refusal by any means.

 


mmix wrote:

 

how is this any different than an ISV holding my client hostage with upgrades to off-the-shelf software package?


For lack of a new explanation here I'll say it again, we are not killing existing scontrols, you can continue to use describelayout from a Visualforce page if that's the only mechanism that serves the metadata you need. Is it ideal? No. Can you benefit from all the other aspects of Visualforce? e.g:

 


 durable L&F through apex:* controls, the whole works, the pageBlocks, the sections, the editors, etc, etc.


 

Yes.

 


mmix wrote:
 

I constantly get asked when we will "upgrade" their wizard from s-controls to Apex/VF and how can we do that when your proposed 'relief' is slower than current s-control version. They do not want to embedd s-controls in page tags, they want to achieve durable L&F through apex:* controls, the whole works, the pageBlocks, the sections, the editors, etc, etc. We are not married to s-controls, we HATE them, but if API's are not compatible then we have no ALTERNATIVE but to stick with s-controls.


First, I don't believe my proposed relief is slower. Second, I don't understand why one AJAX Toolkit call to get picklist describe information would prevent you from moving a client to Visualforce if you value the other benefits as much as you say you do.  

 

I was looking for the answer to this question: if we execute on the application of recordtype awareness for picklists in inputField will that address your issue. I can't really tell if it would for the case that prompted this message so I'll assume the answer is no. This doesn't mean we won't do it and that doesn't mean we won't augment describe in Apex with record type picklist information.  When we do this, for better or worse, can be affected by the ideaexchange. 

mmixmmix

You missed the List<T> part, which implies we have other server side processing we want to do on the list (as opposed to doing all that in JS now), so all 5 steps are needed, plus rectype awareness will not resolve the issue as there is additional business logic checking for invalid combinations of recType, category and subcategory (a logic that is not provided out-of-the-box). However, I have this terrible feeling that I am wasting my time here as you obviously do not want to understand what I am telling nor do you have any intention of passing these comments to decision makers. I can almost bet that come 2010 we'll lose new s-controls and still not have a full Apex API and you'll have yourself at least one pissed off enterprise client.

 

Honestly, I find your reasoning and hiding behind idea exchange very disturbing. While idea exchange is a great and perfect tool to prioritize NEW ideas, its a piss poor mechanism to prioritize technology upgrade paths since you are subjecting your functionality and my clients' operations to the public rule of mediocrity; for any given advanced technique there will be a minority who uses it and a majority that does not, thus guaranteeing that advanced things will never win a popularity contest and will forever remain on backburner. This is a fundamental flaw of Web2.0 and while it might be inconsequential in eCommerce product reviews, here it leads to broken backward API compatibilty (because resources were given to a request with a popular vote), and to make matters worse even people who are not your customers can vote just by registering. Democracy is a great system, but has a known weakness, it can be abused to avoid personal accountability by blaming the masses. Just my 2 cents.

 

Anyway, I think I did my duty (and above) in warning you where your actions are leading you, my conciousness is clear. Do what you wish with this information.

mtbclimbermtbclimber

Thanks for answering one of my original questions:

 


mtbclimber wrote:

 

Would you need it in Apex if inputField respected record type constriction of picklist values?  How are you presenting the options and do you need to do any manipulation on them?

 


 

Unfortunately in your reply to that message I don't see anywhere other than your psdeudo code that comes close to answering this question. I admit I probably should have asked for clarification on this:

 


mmix wrote:

4. I use the information to generate List<T> structure that I need



Had you answered it directly with the information in this latest message I would not have come back and presented my original notion as a solution to your problem.  Typically I try to avoid inferring too much or making assumptions as the last thing I want is to spend time working on a feature that doesn't solve the real needs of developers which brings me to my response to your recent statement:

 


mmix wrote:

 

However, I have this terrible feeling that I am wasting my time here as you obviously do not want to understand what I am telling nor do you have any intention of passing these comments to decision makers.



I am responsible for Visualforce, the Scontrol de-support and, ultimately, Apex. I am a decision maker.  I value each and every interaction I have with developers, this one included. If there is any time being wasted here it's because we aren't communicating well. This is not a rhetorical question, I sincerely want to know: do you really think I don't want to understand your need?

 

Regarding the ideaexchange, I've never said it was the *only* input we use. I have merely stated it was an important one.  Certainly things like Visualforce and Apex would not have come about if we waited for the community to push such ideas to the top of most popular ideas before we delivered them.   Using the ideaexchange is also a way of sharing your need and getting feedback from others, sometimes offering alternate solutions, other times it might induce a new perspective. I'm not saying that would be the case here necessarily but we do value it and hope you can see the value as well, not just for new ideas but anything that may be on our backlog. 

 

Finally, I am not hiding behind it and I don't particularly appreciate the allegation. We (the decision makers) are held accountable for delivering features for which the community asks (again, we deliver other things too) so it is part of my job to encourage people to use it as a means to communicate what will help them.