Page Comparison

It’s better to have a simple ‘incomplete’ adapter that is easily understood and altered by the user than an over elaborate one.

Iguana X is a open system which is intended to allow our customers and do anything. Overly elaborate adapters means that the code is a what we call a Code dump which makes it difficult for other people to adapt and use the code to their own purposes.

This is problem with a lot of Open Source projects.

Sure you have access to the code but that isn’t helpful if it takes months of study to understand it and it the code has many many design flaws that you cannot solve without with years of commitment.

Less is more.

In IguanaX, an open system, we provide adapters as libraries to connect with various applications. These adapters are intentionally designed to be simple and intuitive, making them easily extendable by users to meet their specific needs. This approach contrasts with the complexity often found in open-source projects and the rigidness of complete platforms like Zapier. Iguana's inclusive environment, featuring a Translator, logging, queuing system, and dashboard, though convenient, requires users to invest effort in learning. Our goal is to empower users with adaptable tools, understanding that no adapter can be universally complete.

See:

• Code dump

• Open Source

• Developing in the Translator and

• Logging and Queuing

function ATTLclient(T)
   local S= {}
   setmetatable(S, MT)
   S.key = T.key
   return S
end

So in In the case of Atlassian we need:

• user - I.e. fred.smith@interfaceware.com

• space - i.e. ABC for a Confluence space that has this ID

• key - A unique personal API key for a confluence user

• organization - to construct base URL to our Confluence space, e.g. https://acme.atalassian.net

This adheres with Naming convention for table parameters in Iguana.

These should just be passed through in the table arguments. So the code becomes:

function ATTLclient(T)
   local S= {}
   setmetatable(S, MT)
   S.key           = T.key
   S.space         = T.space
   S.user          = T.user
   S.organization  = T.organization
   return S
end

Now we need to add the API access key to

the project as a Custom Fields. The API access key needs to be treated as password. Thus we create in config.json a custom field named ‘key' of type 'Password’ and store in it the personal Atlassian API access key, respective to the user name in use.

Let’s call our new API method ATTLgetDescendants. We can rename ATTLcustom into ATTLgetDescendants and to rewrite its content.

This method will returns return all pages in a space.

Sometimes Now, sometimes an API method would require a parameter which can be discovered only programmatically. In our example of Confluence Adapter this is Confluence Space Id parameter, which isn’t the same as a Space Key above.

The API method ATTLgetSpaceId will help us to discover this value. Let’s create new Lua file, name it ATTLgetSpaceId and write its content.

Let’s create a simple main.lua file:

require "ATTL.ATTLclient"

A = ATTLclient{
   key          = component.fields().key,
   space        = 'EC',
   user         = 'fred.smith@interfaceware.com',
   organization = 'interfaceware'
} 

function main(Data)
   A:getSpaceId() 
   local count = 2 
   A:descendants{count = count, live = true}
end

Right after declaration of Client instance and passing the parameters to it, we discover the Confluence Space ID. This value couldn’t be known without running this API call.

Next we prepare for paginated API call and require only 2 calls to be executed by setting ‘count’ variable to number 2. This will save the time while testing. The parameters for this method are described in respective help file.

And finally, we request from API to return the listing of descendants for 50 pages.