[x3d-public] [x3dom-developers] Prototype

[doug sanden]

Q1. for import, do you need to say the word 'import' somewhere, just once? If so is that like an ExternProtoDeclare with only a url?
Q2. Or do you say 'import' at each node instance? If so, is that like an ExternProtoInstance, with only a url?
Q3. what happens if you say 'import' but nothing ever shows up? 
Q4. What happens if you route between something in the scene, and something in the import, and the import doesn't show up?
-Doug
more..
When I reworked freewrl's proto and extern proto system last fall, I found I could use the same structure for Scene, Proto (Declare and Instance), ExternProto (Declare and Instance) and Inline, with a few flags to differentiate them. (Flux was similar: if I put an IS in the main scene, it would warn no field was found (on the container Proto) indicating Flux uses the same code to parse scene and protobody)
When instancing an ExternProto, I did it similar to instancing a Proto, except I left the body empty. Later if/when the proto definition showed up after a url download and parse, I would instance one in the ExternProtoInstance body, and do a matching algo to IS-route between the container and contained interfaces.
So for freewrl scene is-a proto is-a inline is-a externproto, with a flag or 2 to differentiate them. X3Dom has scenes and inlines. But no protos or extern protos. 

>
> For x3dom anyway, I'd really like to see the ExternProtoDeclare become
> extinct. Instead, it would import as any other JS API does.
> The declaration exists in one place only, where it is implemented.
> Extern/Proto decs were the main source of bugs for a large project
> I was on (X3D) and it without a tool (would need to have been a custom
> tool) to manage them, it was painful.
>
>
> On 2/21/2015 3:57 AM, Christoph Valentin wrote:
>> Sorry again for answering to an old e-mail
>>
>>>>>>>> with one exception: what about if field definitions in an ExternProtoDeclare
>>>>>>>> don't match the original ProtoDeclare?
>> Should this be discussed on the list?
>>
>> Imho, it should be possible to modify external prototypes without changing the URL and without changing all the <ExternProtoDeclare>s that refer to that prototype.
>>
>> Following modifications should be possible without updating <ExternProtoDeclare>
>>
>> 1) Bugfixes
>> 2) adding behaviour that is orthogonal to existing behaviour in the <ProtoBody>
>> 3) adding fields to the external interface <ProtoInterface>
>>
>> If a user wants to use the new functionality, then he must update his <ExternProtoDeclare>
>>
>> Following modifications should be detected by the Web3D-Browser when parsing the <ExternProtoDeclare> and reported to the user as error
>> 1) removing fields from the <ProtoInterface>
>> 2) re-defining fields in the <ProtoInterface> without changing the field name (except redefinition of default values)
>>
>> All the best