FWD » Core Development » Base Language

Constantin: I have looked at #2002 to see the runtime implementation status of these attributes. It is not clear from the history there.

I then started looking at the runtime code and there is definitely some implementation of most of these attributes. For example, it seems like NAME, TYPE and PRIVATE-DATA have default implementations for most resources (in HandleResource and HandleChain). But it is not clear if there are any missing resources or remaining work on these attributes.

I need to know the state of all of the shared attributes listed in #2002. Can you summarize the remaining work/issues?

Implemented by some resources:
- local-name: x-noderef (pending to be released), soap-header-entryref
- namespace-uri: SOAP-header-entryref, Temp-table, X-document (pending), X-noderef (pending).
For these two, each resource should have its own management.

Not implemented and need generic implementation:
- adm-data, unique-id, instantiating-procedure: there should be a common management for these kind of attributes, as their behavior is the same. If you look in HandleChain.WorkArea, you will see that I use a map to hold the last/first resource in the chain, per resource type. Something similar should be done for these too, and the implementation at the resource class just call the same worker.

COLUMN-LABEL (BUFFER-FIELD), DATA-TYPE, FORMAT, LABEL:
- COLUMN-LABEL is used only by Buffer Field resource
- DATA-TYPE, FORMAT is used by both widgets and Buffer Field
- LABEL is used by widgets, Buffer Field and LAST-EVENT
This is what needs to be done.
- GenericWidget.get/setColumnLabel should call handle.invalidAttribute, and not just throw exception
- DATA-TYPE, FORMAT, LABEL - GenericWidget implements them fully
- Buffer Field resource needs to be implemented AFAIK
- LAST-EVENT:LABEL needs to be implemented

Already implemented:
sensitive: widgets, socket, server-socket all should implement it properly
NAME, PRIVATE-DATA, NEXT-SIBLING, PREV-SIBLING: implemented in HandleChain
type: implemented in HandleResource (and HandleChain extends HandleResource)

As long as the resource is extending the HandleChain class, all is good. And I think all current resources do implement it (Except the ExternalProgramWrapper case, which has its own management, as this is a special case).

It looks like we have a PRIVATE-DATA implementation in both BaseEntity and QueryWrapper that needs to be deleted. Both of these derive from HandleChain which already implements the proper methods.

Greg Shah wrote:

It looks like we have a PRIVATE-DATA implementation in both BaseEntity and QueryWrapper that needs to be deleted. Both of these derive from HandleChain which already implements the proper methods.

Yes, they can be removed.

1. SAX resource is WIP by Evgeny (and I expect all attrs/methods to be implemented, including ADM-DATA and UNIQUE-ID).
2. in the end, each resource contains its own support for ADM-DATA and UNIQUE-ID (I mean, these are saved in instance fields local for each resource).
3. INSTANTIATING-PROCEDURE is being added by #2196 (is still WIP, hope to have an update soon)
4. XEntityImpl.getName and XEntityImpl.setName - this is a question for Evgeny: is the NAME attribute read-only for X-DOCUMENT/X-NODEREF/etc? If yes, then XEntityImpl should override hasNameReadOnly and let it return false; also, override setName and annotate it accordingly (so that the setter will be ignored).
5. NullWidget is something used internally by P2J to reference "unknown widgets"; at some point we will get rid of it, please ignore it for now.
6. expect that TempTableBuilder (and others) to be refactored/restructured with the #1654 task

Constantin Asofiei wrote:

Hynek, some notes:

1. SAX resource is WIP by Evgeny (and I expect all attrs/methods to be implemented, including ADM-DATA and UNIQUE-ID).

Ok.

1. in the end, each resource contains its own support for ADM-DATA and UNIQUE-ID (I mean, these are saved in instance fields local for each resource).

Could you please explain what was meant by "common management" from note-5 above? Progress documentation doesn't indicate these attributes should need any special kind of behavior.

Yes, there's no suitable common parent class for adm-data and unique-id. But the attribute implementations would be trivial so I would not try to create any "smart" common logic. Unless I am missing something here.

1. INSTANTIATING-PROCEDURE is being added by #2196 (is still WIP, hope to have an update soon)

Ok, I am excluding this from my list.

1. NullWidget is something used internally by P2J to reference "unknown widgets"; at some point we will get rid of it, please ignore it for now.

Ok.

1. expect that TempTableBuilder (and others) to be refactored/restructured with the #1654 task

Thanks for pointing this out, will watch out.

SOAPHeaderEntryImpl is heavily unimplemented. Still implement those local-name and namespace-uri attributes mentioned above in isolation? Maybe it would make more sense to implement them together with the rest.

Buffer resource is not mentioned but is also missing implementations for adm-data, unique-id, namespace-uri and buffer-field. Should I ignore or implement?

GenericWidget columnLabel setter/getter should call handle.invalidAttribute not just throw an exception (see note-5). There are more attributes handled by only throwing an exception. Should those be also changed in the same way?

Constantin Asofiei wrote:

1. XEntityImpl.getName and XEntityImpl.setName - this is a question for Evgeny: is the NAME attribute read-only for X-DOCUMENT/X-NODEREF/etc? If yes, then XEntityImpl should override hasNameReadOnly and let it return false; also, override setName and annotate it accordingly (so that the setter will be ignored).

For X-DOCUMENT/X-NODEREF name is readOnly. For X-NODEREF name takes from node and always readonly too. for some nodes name could be specify in constructor for other nodes (like text, which doesn't have name) name will be node type(#text for text node).
UNIQUE-ID may be grouped, for example for sax-reader, sax-writer, sax-attributes they share same unique sequence. Maybe same idea in other object types exists.

Hynek Cihlar wrote:

1. in the end, each resource contains its own support for ADM-DATA and UNIQUE-ID (I mean, these are saved in instance fields local for each resource).

Could you please explain what was meant by "common management" from note-5 above? Progress documentation doesn't indicate these attributes should need any special kind of behavior.

Yes, there's no suitable common parent class for adm-data and unique-id. But the attribute implementations would be trivial so I would not try to create any "smart" common logic. Unless I am missing something here.

I was thinking to have some common storage for these attributes, for all resources (either in some superclass fields or in a dedicated class, per resource); but, this would only complicate the design, and, as you say, adding support for them at each resource is trivial.

SOAPHeaderEntryImpl is heavily unimplemented. Still implement those local-name and namespace-uri attributes mentioned above in isolation? Maybe it would make more sense to implement them together with the rest.

SOAP support is not yet started; you can go ahead and add support for ADM-DATA and UNIQUE-ID (as these are trivial), but LOCAL-NAME and NAMESPACE-URI I think is best to leave them to be implemented when SOAP resources are implemented (as you will not be able to test the behaviour without full support).

Buffer resource is not mentioned but is also missing implementations for adm-data, unique-id, namespace-uri and buffer-field. Should I ignore or implement?

Check #1654, BUFFER resource is part of that task. Stanislav: did you add support for these?

GenericWidget columnLabel setter/getter should call handle.invalidAttribute not just throw an exception (see note-5). There are more attributes handled by only throwing an exception. Should those be also changed in the same way?

First, please double check in 4GL that indeed these attributes are not supported.

Evgeny Kiselev wrote:

Constantin Asofiei wrote:

1. XEntityImpl.getName and XEntityImpl.setName - this is a question for Evgeny: is the NAME attribute read-only for X-DOCUMENT/X-NODEREF/etc? If yes, then XEntityImpl should override hasNameReadOnly and let it return false; also, override setName and annotate it accordingly (so that the setter will be ignored).

For X-DOCUMENT/X-NODEREF name is readOnly. For X-NODEREF name takes from node and always readonly too. for some nodes name could be specify in constructor for other nodes (like text, which doesn't have name) name will be node type(#text for text node).

Evgeny, do you want me to change it? Just let me know, it should be no problem.

UNIQUE-ID may be grouped, for example for sax-reader, sax-writer, sax-attributes they share same unique sequence. Maybe same idea in other object types exists.

This is probably out of scope of this issue.

Constantin Asofiei wrote:

Hynek Cihlar wrote:

SOAPHeaderEntryImpl is heavily unimplemented. Still implement those local-name and namespace-uri attributes mentioned above in isolation? Maybe it would make more sense to implement them together with the rest.

SOAP support is not yet started; you can go ahead and add support for ADM-DATA and UNIQUE-ID (as these are trivial), but LOCAL-NAME and NAMESPACE-URI I think is best to leave them to be implemented when SOAP resources are implemented (as you will not be able to test the behaviour without full support).

Ok, will add support for ADM-DATA and UNIQUE-ID and will leave the rest out.

Buffer resource is not mentioned but is also missing implementations for adm-data, unique-id, namespace-uri and buffer-field. Should I ignore or implement?

Check #1654, BUFFER resource is part of that task. Stanislav: did you add support for these?

The latest code changes from #1654 are missing the implementations for the above-mentioned attributes. Stanislav, are you planning to implement them?

GenericWidget columnLabel setter/getter should call handle.invalidAttribute not just throw an exception (see note-5). There are more attributes handled by only throwing an exception. Should those be also changed in the same way?

First, please double check in 4GL that indeed these attributes are not supported.

Ack, I will post the findings first.

Stanislav, are you planning to implement them?

There are ADM-DATA and UNIQUE-ID attributes for tables. I'm not planning to implement them for buffers.

From this list, only the DATA-TYPE and TABLE attributes are used in appserver reachable code; and, all of them are used with the BUFFER-field or BUFFER resource.

Greg: for M7, my suggestion is to add only proper error support for attributes NOT supported by certain widgets (instead of throwing java exceptions). All attributes which are supported by a widget but their implementation throw a java exception should be left untouched (this way, if we missed something which needs to be implemented, it will be obvious in the logs).

I don't quite understand what the spreadsheet is saying. For example, the DCOLOR attribute is already supported across most (if not all) widgets today. Perhaps there is something missing, but it is not completely unimplemented. Yet the spreadsheet lists it as "not implemented". The GenericWidget exception is really only there such that if we are missing the support in some widget, that we would easily find it. But so long as the subclasses implement the support properly, this error can never be thrown. Before we go too far with a discussion, I'd like to understand what is being proposed here.

Greg: the list is a break-down of widget attributes by their associated widgets, but, as you note, the "P2J support" assumptions are not necessarily correct. And to rephrase my note, what I was saying was that the default implementation in GenericWidget/BaseEntity should not be "throw exception"; it should be a 4GL-style error, as i.e. QUERY is supported only by BROWSE widget; and, as in 4GL GenericWidget is the root class for all widgets, this will allow access to the QUERY attribute for non-BROWSE widgets (this should not be possible).

Some additional notes: from the list at note 3, work should be done at this task only for UNIQUE-ID, ADM-DATA, NAMESPACE-URI and LOCAL-NAME attributes - make sure all resources which are already implemented in P2J implement them properly. They should be implemented now only if the attribute implementation is not resource specific.

The implementation for the remainder of those mentioned at note 3 is very resource specific and there is no reason to implement them here.

Agreed.

Greg Shah wrote:

I don't quite understand what the spreadsheet is saying. For example, the DCOLOR attribute is already supported across most (if not all) widgets today. Perhaps there is something missing, but it is not completely unimplemented. Yet the spreadsheet lists it as "not implemented".

In this particular case DCOLOR getter is not implemented.

The GenericWidget exception is really only there such that if we are missing the support in some widget, that we would easily find it. But so long as the subclasses implement the support properly, this error can never be thrown. Before we go too far with a discussion, I'd like to understand what is being proposed here.

Yes, I was accounting for this. In case the subclasses (for ALL needed widgets) properly implement the attributes I don't mention the attribute in the table.

Constantin Asofiei wrote:

Greg: the list is a break-down of widget attributes by their associated widgets, but, as you note, the "P2J support" assumptions are not necessarily correct.

I created the table based on the answer from Constantin at the note 17. I noticed that there are more unimplemented (or wrongly implemented) attributes in the GenericWidget class hierarchy. I raised the concern and interpreted the answer such that I should do more investigation on these suspicious attributes.

The table shows the expected 4GL state (column "4GL support) and the actual P2J state (column "P2J support") and the work delta to bring the expected state into the actual state (column P2J TBD). I quickly went through the data again and don't think there are many wrong assumptions. The only one I see is that the DCOLOR mentions the setter as not implemented while only the getter is not.

Some additional notes: from the list at note 3, work should be done at this task only for UNIQUE-ID, ADM-DATA, NAMESPACE-URI and LOCAL-NAME attributes - make sure all resources which are already implemented in P2J implement them properly. They should be implemented now only if the attribute implementation is not resource specific.

Please focus on this part.

• AbstractTempTable.getADMData - as BDT types are mutable, never expose the private reference to the outside world. always return a new instance.
• add Override annotations to the AbstractTempTable.getADMData and AbstractTempTable.setADMData (make sure all the APIs you've changed/added have this annotation, when appropriate).
• some files are missing history entries
• remove the SAX_ATTRIBUTES/SAX_READER changes - this will be added by #1641 (more, the UNIQUE-ID "seed" is the same for all SAX resources).

Constantin Asofiei wrote:

Hynek, changes look good, nice catch with the UNIQUE-ID/ADM-DATA for a procedure resource (that it should not be saved at the ExternalProgramWrapper instance). Please also move to the ProcedureManager$ProcedureData the ExternalProgramWrapper.instProc field (I should have remembered not to add persistent data to the ExternalProgramWrapper class); the logic in the ExternalProgramWrapper c'tor remains the same, just save it at the associated ProcedureManager$ProcedureData instance.

Will do.

Also, some notes about the update:

• AbstractTempTable.getADMData - as BDT types are mutable, never expose the private reference to the outside world. always return a new instance.

Yes, very true. Actually I moved the getter/setter implementations from TempTableBuilder and missed the simple return.

Will fix.

• add Override annotations to the AbstractTempTable.getADMData and AbstractTempTable.setADMData (make sure all the APIs you've changed/added have this annotation, when appropriate).

Same as above. Will fix.

• some files are missing history entries
• remove the SAX_ATTRIBUTES/SAX_READER changes - this will be added by #1641 (more, the UNIQUE-ID "seed" is the same for all SAX resources).

Ok, will fix.

1. I would prefer to have a ProcedureManager.setInstantiatingProcedure(Object referent, handle instProc) instead of ProcedureManager.assignThisProcedureToInstantiatingProcedure. The code in ExternalProgramWrapper c'tor will look like:
   

   ProcedureManager.setInstantiatingProcedure(referent, ProcedureMangager.thisProcedure);
   

2. leave ProcedureManager.resolveInstantiatingProcedure as is and add a ProcedureManager.getInstantiatingProcedure(Object referent). The implementation of ProcedureManager.resolveInstantiatingProcedure is needed as is. The code in ExternalProgramWrapper.instantiatingProcedure will look like:
   

   handle instProc = ProcedureManager.getInstantiatingProcedure(referent);
   return ProcedureManager.resolveInstantiatingProcedure(instProc); 
   

PS: the ProcedureManager.getInstantiatingProcedure(Object referent); will perform no validation, will return the handle as it was saved.

1222a.zip looks good, go ahead and get it regression tested.

OK, the location is the right one, but you need to do it only if we are starting an external proc; also, remove the ProcedureManager.setInstantiatingProcedure and set the field directly:

            // setting INSTANTIATING-PROCEDURE can be done only after ProcedureData is created
            if (bt.equals(BlockType.EXTERNAL_PROC) && TransactionManager.getNestingLevel() > 2)
            {
               // if this is not the entry point, set the INSTANTIATING-PROCEDURE as the current 
               // THIS-PROCEDURE
               pdata.instProc.assign(ProcedureManager.thisProcedure());
            }

OK, remove the ProcedureManager.setInstantiatingProcedure (because is no longer used and it will just confuse readers) and you can release it.