Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Element type nodes #2468

Merged
merged 1 commit into from
Jan 13, 2020
Merged

Element type nodes #2468

merged 1 commit into from
Jan 13, 2020

Conversation

SHKnudsen
Copy link
Collaborator

Purpose

This PR introduces an ElementType category to the Dynamo library, all other Dynamo types (WallType, FloorType, etc.) now inherits from ElementType which means a lot of duplicated code has been removed.

The following new nodes have been added:

ElementType nodes

ElementType

WallType nodes

WallType

FloorType nodes

FloorType

RoofType nodes

RoofType

All of the nodes have related unit and system tests, which has been run in RTF before submitting.

Unit Test

ElementType_UnitTest_030120

System Test

ElementType_SysytemTest_030120

Declarations

Check these if you believe they are true

  • The code base is in a better state after this PR
  • Is documented according to the standards
  • The level of testing this PR includes is appropriate
  • User facing strings, if any, are extracted into *.resx files
  • Snapshot of UI changes, if any.

Reviewers

@AndyDu1985
@radumg
@mjkkirschner
@ZiyunShang

FYIs

Screenshots of the dynamo graphs for the system test

ElementType Properties test

CanGetElementTypeProperties

ElementType by name test

CanGetElementTypeByName

Duplicate ElementType test

CanDuplicateElementType

ElementType get preview image test

GetElementTypePreviewImage

WallType Properties test

CanGetWallTypeProperties

WallType Thermal Properties test

CanGetWallTypeThermalProperties

Check if FloorType is foundation slab test

CanCheckIfFloorTypeIsFoundationSlab

get FloorType structural material test

CanGetFloorTypeStructuralMaterial

FloorType thermal properties test

CanGetFloorTypeThermalProperties

RoofType thermal properties test

CanGetRoofTypeThermalProperties

* Element.GetSubComponents (#16)

* Element.GetSubComponents node with icons
* Element.GetSubComponents tests

* ElementTypeByName node

* ElementTypeByName tests

* Created ElemetType class

* made types inherit from ElementType

* node images + small fixes

* element and wall type tests

* Update WallTypeTests.cs

* ElementType tests

* WallType, FloorType and RoofType tests

* Revert sample DYN files

This reverts commit 38bd219.

* comment updates

* change var to int
@SHKnudsen SHKnudsen changed the title Element type (#25) Element type Jan 6, 2020
@SHKnudsen SHKnudsen changed the title Element type Element type nodes Jan 6, 2020
@mjkkirschner
Copy link
Member

mjkkirschner commented Jan 6, 2020

This PR has API breaking implications. You must be very careful when refactoring like this - Code which previously was written on top of the DynamoRevit node classes now has the potential to break.

It's difficult to say what will happen unless it is throughly tested. But I know for certain that this breaks a few public APIs and as such should not be released as a DynamoRevit 2.x change.

In general you should not change the type or signature of public members until you are ready to break an API.

https://stackoverflow.com/questions/1456785/a-definitive-guide-to-api-breaking-changes-in-net

for example, this similar PR broke lots of code:
#2282

If you intend to get this into 2.x then I would act as conservatively as possible, do not refactor these classes, but add additional methods to Element using a new interface, and obsolete old properties.

If you intend to get this into 3.x then leave this PR open and maintain it (merging master) until DynamoRevit intentionally decides to break API compatibility- that could be today! - but thats for @ZiyunShang @AndyDu1985 and Minjie to decide think.

@radumg
Copy link
Collaborator

radumg commented Jan 7, 2020

Thanks for the notes @mjkkirschner , it's an interesting issue! I hadn't originally flagged this as an issue in our internal review as the signature of the classes will essentially resolve fine at run-time, but now realise I hadn't considered whether Dynamo uses fully qualified names when compiling nodes/etc.

Would be great if you could give us a few examples of the APIs that you know will break, would love to test those a bit more. If it's still an issue, we can take a more conservative approach, no probs.

/// </summary>
/// <returns name="ElementType">Element Type or Null.</returns>
public Element ElementType
public ElementType ElementType
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@radumg here is an example of a simple API break - this class no longer has as property called Element.

using RevitServices.Persistence;

namespace Revit.Elements
{
/// <summary>
/// A Revit RoofType
/// </summary>
public class RoofType : Element
public class RoofType : ElementType
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for any of these types which now have new base classes, it might be fine, or it might not, it's worth considering a package which used this type as the input to a node or even just internally, will this code need to be recompiled? Will it need to have changes made and then recompiled?

Can you prove it won't?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, it looks like you did not have to modify any existing tests? That is usually a good sign for these type of refactors.

I think the best that can be done, if you want to move forward with a refactor like this is to try this change out on a package that was compiled against an old version of DynamoRevit and see what happens. This can be run as an automated test.

also, please see the one change which looks to be a genuine break.

@AndyDu1985 AndyDu1985 merged commit 391e46f into DynamoDS:master Jan 13, 2020
AndyDu1985 added a commit that referenced this pull request Jan 13, 2020
AndyDu1985 added a commit that referenced this pull request Jan 13, 2020
@AndyDu1985
Copy link
Collaborator

@SHKnudsen This PR cause build failure, I've revert it, could you resend a new PR? Thanks!

AndyDu1985 added a commit that referenced this pull request Jan 15, 2020
@SHKnudsen SHKnudsen mentioned this pull request Jan 24, 2020
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants