fractalide / fractalide-oz

Proof of concept
GNU Affero General Public License v3.0
12 stars 3 forks source link

make component description mandatory + sub-component description #60

Open dmichiels opened 10 years ago

dmichiels commented 10 years ago

For the moment, the creation of a component require only two mandatory fields : name and type. The idea is to make the description also mandatory. Even if the description will stay empty, that will force the developer to think about it at least a moment. Description will be very important for the sharing of the components.

Also, there is no possibilities to put description for a sub-component (a .fbp file). Perhaps can we force that the first lines are comments. This comment will be the description, until the first empty line.

% The graphPanel allow to change the topology of the card

% Action flow
awIn() out -> in awOut() ...
...
sjmackenzie commented 10 years ago

These are great ideas!

I agree description should be mandatory.

Also bear in mind that there should could be license information at the beginning of the file.

How about:

"This is a comment" -> description this(this)

Now once fractalide gets its own editor we could have a template for a new file.

dmichiels commented 10 years ago

Ah yes, right for the license. Your solution is better. What about :

awIn() action#getDescription -> START description(genopt) output => description
"This is the description" -> options descritpion()

Or more simply

"this is the description" => description

So that sub-component have an description output port, and if you want the description, you can simply see the IPs going out of this port.

sjmackenzie commented 10 years ago

"this is a comment" => description

Is best, it's the most simple way, and intergrates with the rest of the system.

you could make it mandatory by checking in component.oz for a description.

sjmackenzie commented 10 years ago

Actually this might be a simple way to determine if an application is the main entry point (on the runmode screen)

"component" => type (or keep it blank)

Or

"application" => type

If fractalide sees "application" coming from the type port then it sticks that component onto the runmode canvas.

secondly we could encapsulate the icon too:

"/path/to/icon.png" => icon

Then fractalide loads up and displays the icon.

Seems neat and succinct? Do you like it?

dmichiels commented 10 years ago

we touch the solution, but I think that we need something more flexible and dynamic. And I just thought that we need somethings like the "options" port on component. I see here at least two problems : 1) Start : the IPs will be send once when the start action will be send to the sub-component. That is not ideal, because we will perhaps need to have an options after. 2) Scalability : Hard coded all possible options seems not the best solution for me. We need more dynamism!

We can perhaps implement this feature in a card :

option => in options(options) out => options
'set("this is the description")' -> option#description options() 
'set("application")' -> option#type options()
'set("/path/...")' -> option#icon options()

We will be able to get them with :

'get' -> option#description thesubcomponent() options#description -> ...

What do you think?

sjmackenzie commented 10 years ago

hey looks great!