Closed DanielAbalde closed 3 years ago
Linked with COMPUTE-213
What would you do when more than one path is passed to the component?
Ideally it would be a custom wire like Gh timer or Galapagos does. But for the moment, it just take the first value in a tree access input inside BeforeSolveInstance() and ignore more values.
And also as I want to define parameter constrains where path definitions must match, parameters are defined when the component is added to the document or overriding the component to create template components.
Any opinions?
I need to restructure code for #326 as well as for allowing compiling of CPython based servers into GHAs.
There is also a request to optionally add a fixed 'enabled' input which is similar to this issues for adding a 'path' input (#327). It may be possible to do all of this without creating a new component, but I haven't put enough time and effort into this issue to really know.
I don't see how this can help to my goals. What I need is to change the path procedurally. I asked for an abstract RemoteComponent to be able to do that. Also overwriting Hops makes it impossible to build on top because there may be changes that require reconnecting things, that's why I have stopped working on this, instead with a RemoteComponent I would only have to recompile with the latest version.
On the other hand, aren't you interested in a special wire like Timer does, to conserve Hops without the Path input but allowing to connect this wire to a panel or text/file parameter in an equivalent and alternative way to setting the Path from the component's menu? This way you only need to include a GH_AbstractInteraction and custom attributes to connect Hops to a text/file output without the output solution forcing Hops to re-solve itself (except if the path changes, the implementation must handle this). I have enough experience to write this but since I don't know how stable the Hops code is, it's not worth it for me at the moment.
My last comment included the possibility of changing the path procedurally without creating a new abstract base class.
I don't currently know how the special wires like Timers work. It does seem worth investigating.
@DanielAbalde do you still need this functionality as hops now allows for a path input?
@sbaer I wanted to make my version of Hops to avoid that hard coded parameter constrain, to remove having to use groups for output names and to define an input and output parameter signature that restricts the definitions that can be opened (the available definitions have the parameters of the signature). I wanted to explore where it could take me with the possibility in mind of offering pay-per-use definitions someday or an online definition search engine of definitions made by the community on my plugin... I think that several types of remote components could be made, I don't think it's right that there is only one object responsible for this functionality with so much potential instead of offering it in the SDK open to interpretation. So, it wasn't just about including a variable path, but you can close this issue if you want to, as you seem to have a different understanding of your tool.
Hello.
How about separating the logic of the Hops component responsible for acting as a remote component to an abstract class, and leave the Hops component as a specific implementation?
I was working on a different implementation (with path as input) but it's a lot of effort to keep your development up to date. This way, if you update the Hops specific stuff I don't get involved and if you update the RemoteComponent logic I can update my fork easily. I just do my stuff in my class inheriting RemoteComponent with the abstract method DefineInputsAndOutputs(), but SolveInstance() is the same, defined in RemoteComponent.
I've done the work, but it's with your code from a week ago.
` ///
/// Base class for remote components
///
public abstract class RemoteComponent : GH_TaskCapableComponent, IGH_VariableParameterComponent
{
region Fields
`