Component development

Component development

  
I want to develop a component to be reused in several application I have in mind.
I'm looking for a guideline how to develop components, but Im not able to find none.
Are there any rules? Is there such kind of document?

Are you aware of the Components Download Area?

http://www.outsystems.com/NetworkSolutions/Home.aspx


You can find there a lot of components developed by the community.
RichWidgets e-Space is a good example where you can find components reused in several applications.

I hope this reflects your thoughts.

Cheers.

Daniel Martins.
Thanks for the replay.
Yes, I'm aware of the components download area.
What I want to know is, if there is any documentation, on how to develop components, and if there are any rules that we have to respect in order to develop and publish components for others to use.

Thanks again
Antonio
Hi António.
I'm not aware of any documentation regarding the subject.
However I believe component development practices should just follow programming best practices, with a few more considerations into the mix.

I've developed a few of those, so here's what's on my mind whenever I'm "at it". :)
A component should be as simple to use as possible. People want to use it as-is (damn you iDevices...). Think of it as a product (or a CLASS) for developers
With this in mind
  1. Keep all your parametrization exposed in some way and parametrize as much as possible. No one should EVER have the need to peek into your code just to be able to do "something else".
  2. Keep your code simple/readable in case .1 is not enough for someone.
  3. Scalability. Keep your component as scalable as it can be or: a) It may fail to work in future releases of the platform, and you find out it's hell to debug/upgrade it b) You might find it difficult to add more features as upgrade ideas often come to mind after the component is released to the public and the community provides feedback in an awesome collaborative way. :)
  4. Make it fast. Because you are releasing a piece of reusable code to be used by someone/somewhere in a situation that you will never know, your component must be as fast as it can, so it can handle even the worst transaction/processing nightmares. So pay some attention to performance.
Looking forward to hear from someone else about the subject. If this thread somehow turns into a busy discussion, we could even gather all the input and make a thread to fill the (apparently) existing gap on the subject.

"Share freely, investigate deeply, and improve constantly" :-)
Additional consideration to António post:

1) Naming: If you build a component that connects to a 3rd party web service to provide functionality to the agile platform, consider naming your component after the company name. However if your component is a general purpose component that will be used to connect to various 3rd party web services to provide a specific set of functionality, consider a meaningful name.

Example:
A social networking component designed specificially only to support facebook, you would title your component Facebook.
A social networking component designed to support various social networking, Facebook, google+ twitter, etc your would title your component "SocialHub" or some other meaningful name.

If you are unsure what to name your component, or give it a general name and meaningful name, that represents the purpose of your component.

2) Reduce dependency: You should attempt to reduce dependency as much as possible. 

3) Reusable and configurable by many applications:
You should design your component to be reusable by many companies, and also design your component to be reusable by many applications within the same company (ie within the same agile paltform enviroment).

More than one application within the same agile platform environment should be able to consume the same reusable component; where each consumer application would have its own configuration to suit its own needs.

Example
You build two applications, a developer's portal, and a content management system/blog application, both of these applications consumes a twitter component that you have built. The primary company's twitter acocunt used to tweet on your company's blog page, might be different from the twitter account that your company use to  tweet on your developer's portal. Therefore your component should be designed to be reusable and configurable by many applications within the same agile platform.


Other points to consider when designing a component: 

Components should be....
-easy to use, even without documentation and hard to misuse

-easy to read and maintain code that consumes your component

-Easy to extend

-Designed to be simple and not over constrained with features that may not meet everyone's needs (designed your component to be simple with the aim of displeasing everyone equally)

-Functionality, when it doubt leave it (It is always easier to add features rather than remove features)

-keep all complex implementation private within your component, and expose only public actions that are simple to understand and use; 

-All names should be self explanatory

-Be consistent with words, the same word should mean the same thing everywhere!

Hello
Thanks for all the valid input to my questions.
But I'm really green on this. Can we start from the begining? I dont forget that "there are no dumb questions.", so here it goes some simple question.
 
The components are developed in Service studio, am I correct?
If no, Where can I develop it?
If yes, I can develop it just like an espace, but....? What are the diferences?
And then, what would I do with it? Publish the oml? I saw components with oml and xif inside (twitter).

As you can see this are pretty basic questions.
Maybe there is clear info in the site about this but I cant find it.

Thanks again

Antonio
Hello Antonio

Components can be a mix of espaces (OML) and extensions (XIF) bundled or not in solutions (OSP). They are just like you own applications, no differences at all, although you do should go through the good practices that were already stated.

Depending on the type of component you're building, you might need an espace, or just an extension. If you have both, it's common to bundle it into a solution.

eSpaces (OML) are created in Service Studio, from scratch or just by opening an existing one. You can create a new Application (which is also an espace) and it will bring a lot of common webbflows, referenced webblocks, actions and entities, and themes. Or you can create a Blank espace that will have none of that, so you can really start from scratch.

If you want to create a UI widget, then you definitely need to create an espace, usually with some public webblock that can be referenced by the developers to use your widget.

Extensions (XIF) are created on Integration Studio, usually from scratch. Extensions allows to define actions, structures and import data models into entities from external sources. You can code (in .NET or Java) your own action which then can be referenced by any espace, or define structure datatypes to be used by those actions or not in the espace, and even import external data models into entities through Database Connections that will be used by the espaces.

If you want to create a connector to a legacy or third-party system, you can code it in an extension, and expose Actions in the extension to be used in the espaces. Or if you want o create a library to manipulate hashtables, lists, or even a image or math library, all coded in the extension. If this is the case, creating an espace as a sample on how to use the connector or library is a good practice. Which leds me to the next one.

Solutions (OSP) is basically a package that bundles together a set of espaces and/or extensions. It can be created in the Service Center management tool, under the Factory -> Solutions. This will allow you to upload a single file as a component.

When you have you component, either it be a single espace or extension, or a solution with a set of espaces and extensions, you just need to create a New Component on the component's area, upload that file, and fill in the descriptions, and any other information you feel that's important.

There's nothing to it.

Cheers

Miguel Simões João
Thanks! That's what I needed to know. I will mix all information and give it a try in SS and IS. Antonio