Skip to content
This repository has been archived by the owner on Jul 2, 2018. It is now read-only.

Tool for editing component configuration #13

Closed
robhrt7 opened this issue Feb 4, 2015 · 5 comments
Closed

Tool for editing component configuration #13

robhrt7 opened this issue Feb 4, 2015 · 5 comments

Comments

@robhrt7
Copy link
Contributor

robhrt7 commented Feb 4, 2015

Following previous request #5, we break down our ideas to separate tools and tasks.

We want to have a separate command available in bb-cli, that will allow to easily edit any preferences and configuration of component.

This command will expose next actions:

model add property (we are deprecating preferences)
model add tag
model add section-tag
model add feature

Subjects for discussion:

  • name of the command
  • default targets for editing files
  • additional actions

(note that configuration sync command is a separate tool #14)

@robhrt7
Copy link
Contributor Author

robhrt7 commented Feb 4, 2015

Editing properties of the widget, we need to modify as less files as possible.

First, we need to always target main .xml file, and in only in case with some custom type properties (like type="select-one"), we will edit index.html as well.

@igord
Copy link
Collaborator

igord commented Feb 4, 2015

Portal properties are always defined via REST API call. There are 3 ways currently used:

  1. by keeping the xml file which is then imported by some REST client, YAPI or bb rest tool/library
  2. by defining g:preferences inside index.html file which portal imports when widget is submitted
  3. by using Portal Manager Explorer

The proper way is the first one or to keep the property definition in the xml file. The only problem with that is when property needs to be manageable inside Portal Manager and it needs to use select box. Right now, that is only possible by storing enumeration values inside index.html file and by using g:enumeration tag.

I vote for creating proper and complete standard by keeping the property data inside backbase.json file. But until then, we need to do it by having xml file inside the component directory. Whenever that file is edited, bb-cli tool will be used to submit the changes via bb rest to the portal server. Use of g:preferences should be discouraged unless for specific case that is mentioned above.

@operatino the commands that you are proposing would be another new way to submit preferences to the portal. I propose that instead, we have one simple command that will parse the xml file(that you will use anyway) and submit changes via REST API call to the server. If you want to add property, just add new property tag to xml. To remove property, just delete property tag from xml file. Same goes for tags or other changes in xml file.

Because this was already planned and defined at bb-cli proposal I say that magic simple command should be:

bb auto --prop
bb auto -p

and in case that you want to have watch process that will submit changes on every file change:

bb auto --prop --watch
bb auto -p -w

@robhrt7
Copy link
Contributor Author

robhrt7 commented Feb 5, 2015

@igord, I agree with your current statement. But another thing to discuss is the name of bb auto command.

Regarding proposed commands list in the body of the task, it's not for submitting preferences to remote model, but only for local file changes. Correct me, if I'm wrong, but I first thought that @GuilhermeMedeiros and @craigwalkeruk wanted to have command that just add properties to local files.

As I see it, you run bb model add property, get prompted with questions and as an output get updated files. Optionally this command could run bb sync/auto after exposing local changes.

@igord igord closed this as completed Feb 9, 2015
@robhrt7 robhrt7 reopened this Feb 9, 2015
@robhrt7
Copy link
Contributor Author

robhrt7 commented Feb 9, 2015

@igord, this task is about separate command, that adds preferences to sources, no sync, like bb auto does.

@igord
Copy link
Collaborator

igord commented Feb 9, 2015

Is there anyone that really wants that or it was misunderstanding?
Adding commands that will change tags in xml file seems like overkill to me.

@igord igord closed this as completed Sep 1, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants