Clarification for "MoreThanOneEntryPointInMxml" needed

[smirnoff81]

Hello,

What is the reasoning behind the "MoreThanOneEntryPointInMxml" violation?

Its description says:

"There are more than 1 public variable in this MXML component"

Why .as files are ok to have more than one public variable but .mxml files are not?

Why does the Flex FW itself provide a lot of UI components which have multiple public vars but FlexPMD considers such components as not well designed ones?

Thanks,

Smirnoff

[Jandr123]

I am wondering about precisely this same thing, and I am surprised that there still is no answer after all this time. Someone took the time to devise and implement this rule. Surely he/she must have had a good reason for it?

[Guest]

Sorry for the sooo late answer to that...

the idea behind this rule is to promote the usage of Presentation Models. A view should only have as an entry point a PM, everything else required by the view should be injected through the PM and consumed by the view then by bindings.

A common problem we've identified with multiple entry points in views is that:

1. The order in which the parameters are set can change the behaviour if the validation/invalidation pattern has not been properly implemented

2. Injecting the dependencies through a PM can somehow give developers on Binding execution. i.e. having multiple entry points could potentially trigger bindings several times. If everything is in a PM then Bindings will trigger only when the PM is injected.

[Jandr123]

sorry that I don't understand, but this reply seems to miss the point made in the original question. Why is it OK for the flex components to have an almost limitless number of variables, like for instance:

<mx: Button id="button1" label="button one" left="30" verticalCenter="0" click="somefunction()"/>

but if we try to build one ourselves, more than one variable violates some guideline? It looks like ALL flex components need intensive refactoring which seems unlikely, so I have probably missed some essential bit of information/education. Please clarify a bit further?

[Xavier_Agnetti]

Hello,

I agree with Xavi's previous reply, you also raised a good question: Why does not it apply to the SDK?

You don't build an application like you build a SDK.

You do have some business logic in you application, whereas the SDK team does not have any business logic to deal with.

The rule is more a guideline, that you can bend if you need to.

If you append to build a SDK for other developpers on top of the SDK, then I would disable that rule.

But again, all the points mentioned by Xavi are absolutly right.

Best

Xavier