nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OO programming with FormApi DELETED

def

Post deleted by def

Find more posts tagged with

Comments

Dwayne

Forgive my bluntness, but your post sounds like something written by somebody who's knowlege of programming consists of hearing a few buzzwords, with no real experience.

As the name implies, FormAPI is an API, not a programming language. The language that's used as the basis for FormAPI is JavaScript.

JavaScript does have some rudimentary OO structure, and FormAPI makes use of it. After all, an IWItem certainly looks like an object to me.

--

Current project: TS 5.5.2/6.1 W2K

def

Well, I am aware of FormApi's use of OO structure, as it uses all those Classes and their properties and functions. Sorry I phrased it wrong. What I meant to say, when prople program in JavaScript using formApi, why don't they "extensively" practice customized OO structure( not those DOM methods). To make my point clear, what are the overheads of using such design? IF anybody knows....
thanks for the sarcasm

Adam Stoller

What I meant to say, when prople program in JavaScript using formApi, why don't they "extensively" practice customized OO structure( not those DOM methods). To make my point clear, what are the overheads of using such design?

I don't think you made youself any clearer here. Perhaps if you posted a code example of what you've seen and what you think it should be written like - that will give the rest of us something to discuss.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

def

At various work places I have seen similar functions with little variation being implemented at different scripts, so far I've followed that route. Lately I started considering designing classes that could provide architecture for similar templates, and with overriding functionality may be the child classes could modify according to their need, or simply the objects of that class could inherit the properties as is. I am considering this alternative as so far I've seen only using include files for javascript, where in a giant file you keep all the common methods and call them as you need. Wondering if there's any way to organize them better, i.e. group them in more structured way. I know this can be done with OO JS, but what would be the downsides?
Hopefully I made myself clearer.
Thanks for you patience ghoti

Adam Stoller

I don't think there would be any downside, as such, to making the javascript code more OO - but I'm not sure how well the functions that people tend to write really fit into an OO model.

We're basically writing routines to augment aspects of an already existing object (IWitem, IWDatacapture, etc.) and while it might be possible to sub-class or super-class such objects I think you would find it more confusing to do so.

Creating libraries of routines in one or more include-able JS files is relatively clean - I've basically done this with one "global" include file that covers general functions for all my DCTs and another include that is DCT-specific which makes use of the "global" functions and defines DCT-specific functions as required.

I suppose you might be able to OO-ize these files, but I'm not sure you'd really gain anything (I'm also not sure you'd lose anything, but ...)

Again though, I think it would be more interesting / revealing, if you could provide examples of JS/FormAPI code that you've seen used - and how you would re-write it to be OO - along with any comments about what you think you'll gain by having done so.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

def

Hi ghoti,
at this point I only have lists of functions used in various templates at my company, that list containts only a portion of all the templates, and I've discovered a lot of redundancies, many instances where a generic method would do rather than 25 copies of the same code. I'll do little more research, and promise I'll post my findings in this forum. If we end up OO-izing our javascripts, I will post a outline of the design, and what we gain....and if we don't, I will explain why....
Sorry I couldn't give any more details...
Thanks for sharing your views....

JonathonG

While I would agree that it is best to centrally manage js code, rather than copy it into several places, I disagree that OO is the way to go. Basically, this is because JavaScripts "object-oriented" syntax is some of the most cumbersome stuff I've ever seen. It works great if you're using some built-in objects, but there does not appear to be a clean way of defining one's own objects/class hierarchy. I've seen ways to define custom classes, but no way of doing inheritance/polymorphism/overloading/etc.

Perhaps my research was deficient when I went looking. If so, I'd be more than happy to have someone correct me.

Jonathon
Interwoven Developer
Allstate, Inc.

brandon1

The mechanism of inheritance does exist in JavaScript. Here is a link to a concise description of that.

http://www.crockford.com/javascript/inheritance.html

Current Project: Content Services implementation

def

thank you brandon!! that link is quite helpful. It cleared a lot of my doubts about JavaScript's inheritence mechanism.