Comments for jonathanrico.

Comment on Autocomplete component by jonathanrico.

jonathanrico. — Mon, 09 May 2011 06:30:39 +0000

Hi Charan,

It should work on any Input Field, however I’d recommend you to hold on a little.

This component is out-dated, salesforce changed the behavior of the id attribute and this is causing some problems with this version of the component.

My company is about to release a free and improved version of the autocomplete component, hopefully you’ll be able to download through the appexchange during the next week.

I’ll reply to this comment as soon as the component goes public.

Comment on Autocomplete component by Charan

Charan — Wed, 04 May 2011 17:21:54 +0000

Awesome work Jonathan.

A small question:

Does it Work for only input field or we can do it for Input Text component also?

Comment on Interesting ways of architecting Apex Triggers by jonathanrico.

jonathanrico. — Mon, 18 Apr 2011 18:40:11 +0000

Oops, it seems that the code is not showing up here. There seems to be an issue with the code plugin for my site, I’ll try to fix it asap.

Comment on Force.com commandments by jonathan

jonathan — Tue, 29 Mar 2011 00:27:12 +0000

Exactly Angel,

It depends on what you’re doing. I must admit that even though I understand the power of dynamic Apex, having Force.com validate any changes in the metadata that might impact my classes makes me feel “safe”. Dynamic Apex can save you a lot of headaches, but I’d think twice before going with this option.

As for the Partner WSDL, WSC and Tolerado provide a pretty neat way for using the Partner WSDL. I won’t think of it as a “commandment” but it’s a good recommendation.

Comment on Force.com commandments by Angel Abrego

Angel Abrego — Tue, 29 Mar 2011 00:03:11 +0000

I’ll depend on what you’are doing… but I would also say: “Thou shalt try Dynamic APEX and Partner WSDL first”. You’ll need to evaluate the cost/benefit of it, but I think is a good idea to keep it in mind on design phase…
Good post John,

Angel Abrego

Comment on Force.com commandments by jonathan

jonathan — Mon, 28 Mar 2011 15:58:11 +0000

Ezra,

I’m not sure if I understand point 1, how could you replace a field update with a validation rule?

As for point 2, I agree with you. If your business logic is fair simple then you should avoid triggers at all means. However, we should always be careful with not ending up with a mix of triggers and workflows. They end up messing around with each other and we usually end up adding helper classes to avoid recursion.

Thanks for your comments!

Comment on Force.com Apex Merge/Replace Class ;) by jonathan

jonathan — Mon, 28 Mar 2011 15:53:02 +0000

Jatin,

This merge class serves a different purpose.

Mail merge functionality in Salesforce is for creating docs using data stored any salesforce object to populate templates.

The functionality provided by this class helps you to merge two records into a single one and makes sure the children of the “merged” record don’t become orphans.

Comment on Interesting ways of architecting Apex Triggers by Best practice: architect Apex triggers - Cloud Giga at Cloud Giga

Best practice: architect Apex triggers - Cloud Giga at Cloud Giga — Mon, 28 Mar 2011 14:07:36 +0000

[...] gokubi and jonathanrico have good posts about how to write Apex trigger codes in a best practice [...]

Comment on Force.com commandments by Ezra

Ezra — Sat, 26 Mar 2011 19:50:13 +0000

Two to go next to “Thou shalt not prefer a trigger over a validation rule”:

1) Thou shalt not prefer a validation rule over a workflow field update (if it can be done through a workflow field update)

2) Thou shalt not prefer a trigger over a workflow field update (if it can be done through a workflow field update)

Comment on Force.com commandments by jonathan

jonathan — Fri, 25 Mar 2011 19:22:48 +0000

LOL. Not a bad idea.

Thanks JoAnn.