Trying to make sense of Perspective module org.fakester, rad components, etc

Yep, obvious new too this. Is there something special about fakester and rad components?
I Googled org.fakester programming rad component and got a link to :face_with_raised_eyebrow:

With respect to Perspective, what does rad mean?

  • rapid application development ?
  • remote administration daemon ?
  • rational application developer ?
  • ???

Is fakester a real organization? I won’t even start to tell you what my Google search spit out (rolling my eyes).

Is there a standard or convention or requirement for the component id text such as the example Image component (the dancing banana)?
public static String COMPONENT_ID = "rad.display.image";

Can you give me a compass heading?

Thanks again,

I don’t know where you are getting this from, I know Ignition advertises itself as a RAD type software, in which context they mean “Rapid Application Development”, and it is that, once you install it you can drag an drop a few components and have some application up within the day.

No idea what fakster has to do with this. Where did you get org.fakester programming rad component from?

He’s talking about the dummy package name, component name, ids, etc… used in the Perspective module example.

They don’t mean anything.

1 Like

Thank you Kevin.

The one thing that does mean something - in Java, packages are identified with reverse domain name suffix - that’s why you’ll see com.inductiveautomation all around our codebase. Theoretically, when writing a module you should use the same structure for a domain name you own. In practice, that only really matters if you want to publish signed artifacts of your module to something like Maven Central; it doesn’t matter at all to Ignition. But, something to be aware of.

Kevin and Paul both have it right. Guess I should be a little less cute when putting together examples, and will make a point to update the project to use simpler ‘fake’ names of things to avoid confusion.

Gotcha, thank you Paul.



AH HA! Thanks for fessing up :slight_smile:
If your going to do that then I should probably clean up my code comments and remove the lamenting and curse words (bahahaha)…or not… :slight_smile:

1 Like

On this note - the 'rad' is similar to the package naming idea - to better avoid the potential for ids to collide. If we (IA) gave the Button component an id of just "button", and someone else created their own button implementation for their Perspective Component module, but used the same ID, that would create problems.

"Namespacing" the component ID (and adding a little more context like 'input') helps avoid these collisions and also gives more info when the ids are logged or found in a debugger.

Okay, I’m getting it now, like tag a tag naming convention. It probably make sense to have a data base (or dare I say ‘spreadsheet’) with all component IDs to make sure we don’t use one that’s already been used. I suppose the build script could be modified to do this during a build and fail if a duplicate was detected, that’d be clever. Thank you Perry. I guess (hope) one last question…so why are you calling them ‘rad’ components? rad must have some meaning to you?

Sadly, nothing special, probably just the first word that came to me when I was thinking of some arbitrary name for the example module. Was trying to avoid people thinking there was any meaning; for those of us that grew up in the 80/90/00s in the U.S., "rad" was just a term that meant "really neat" or "awesome". Should have known better in an (international) industry so heavy on acronyms and initialisms!

So guess you could say the use of rad was a little tongue-in-cheek, because there's nothing really neat about the components (well, aside from educational value).

Radical…ROFLMFAO! I grew up with vacuum tubes and rabbit ears so when I use ‘old’ terms like ‘bread’ nobody knows I’m referring to money.

1 Like