Limitations of Web modeling editor and help with connecting custom generator with web editor

[miloss01]

I made Spring code generator based on B-UML DomainModel written in python code. Next step would be to connect web editor with spring generator.

Example of calling:

generator = SpringBackendGenerator(
        model, spring_boot_version="3.5.11", java_version="17", app_name="Transformers", output_dir=current_dir / "backend", package_name="com.transformers"
    )

Can you share any tutorial, documentation or something else on how to connect those two?
What are limitations of web editor in regards of translating what is drawn to DomainModel (I'm mainly interested in Property, BinaryAssociation, Class etc. classes since those are what I used the most)?

EDIT:
I successfuly started web_modeling_editor/backend/backend.py and api is working locally (checked only @app.get("/besser_api/") endpoint).
Since this endpoint @app.post("/besser_api/generate-output") (backend.py at 357) accepts DiagramInput I first need to populate that. Can you explain it's fields?

class DiagramInput(BaseModel):
    id: Optional[str] = None
    title: str
    model: Dict[str, Any] ///// how should I populate this? and do I need to populate anything else?
    lastUpdate: Optional[datetime] = None
    generator: Optional[str] = None
    config: Optional[dict] = None
    referenceDiagramData: Optional[Dict[str, Any]] = None

After that, I need to add my generator to SUPPORTED_GENERATORS (backend.py at 29). I guess it would go something like this:

"spring": GeneratorInfo(
        generator_class=SpringBackendGenerator,
        output_type="zip",
        file_extension=".zip",
        category="web_framework",
        requires_class_diagram=True
    ),

Then in _handle_class_diagram_generation (backend.py at 556) method add if statement for spring, something like this:

if generator_type == "spring":
        return await _generate_spring(buml_model, generator_class, config, temp_dir)

Then make _generate_spring method that would be similar to _generate_django method.

After that I think that should be it. Right? Main thing here is how to get that json body representing DiagramInput for request, mainly model field. Since I have test model written in python classes using besser Property, Class etc. is there a method or api endpoint or something to transform that in what I need for DiagramInput? Basically, if those steps to add generator to api are good, how can I test that api point for my generator?

As I can see, endpoint is using this method for transforming json data to buml: def process_class_diagram(json_data): (class_diagram_processor.py at 50) which is fine since DomainInput has field model which this method use to extract model data (elements and relationships). But method def class_buml_to_json(domain_model): (class_diagram_converter.py at 92) doesn't make json compatible with previous method.

So, how do I get from something like this:

model = DomainModel(name="some name", types={user, thing, computer, role, hand}, generalizations={gen1}, associations={assoc1})

to valid DiagramInput so that I can test spring generator?

EDIT 2:
Seems like I did it following steps above. Testing is done like this:

json_model = class_buml_to_json(model)

    import requests

    res = requests.post("http://localhost:9000/besser_api/generate-output", json={
        "title": "spring backendaa",
        "config": {
            "spring_boot_version": "3.5.11",
            "java_version": "17",
            "app_name": "Transformers",
            "package_name": "com.transformers",
            "project_name": "trans"
        },
        "model": {
            "elements": json_model["elements"],
            "relationships": json_model["relationships"]
        },
        "generator": "spring"
    })

Any advice or thought if this is ok is welcomed.

What I noticed immediately is that Property.is_id is not registered since when I generate through code it is set to True but when transforming between DomainModel -> json -> DomainModel it doesn't seem to be set on True. In other issue is mentioned that Property.multiplicity is also not set which I also see now just like is_id. Are there any more limitations like this?

[ArmenSl]

Hi @miloss01!
Your integration approach is correct. The steps you followed (registering in SUPPORTED_GENERATORS, adding a handler in _handle_class_diagram_generation, and using class_buml_to_json to build the DiagramInput) are exactly how the other generators are wired up.

Regarding the converter limitations you found:

You're right that Property.is_id is not currently preserved during the JSON↔BUML round-trip (not added into the editor too),it exists in the metamodel but was never integrated into the converters. We're aware of this gap.

Here's a summary of what is and isn't handled for class attributes:

Field	Round-trip supported?
name	Yes
type	Yes
visibility	Yes
is_optional	Yes
default_value	Yes
description (metadata)	Yes
is_id	No : not serialized/parsed
is_read_only	No : not serialized/parsed

For association ends, multiplicity, is_navigable, and is_composite are handled. However, aggregation relationships cannot be round-tripped, they come back as bidirectional associations because the B-UML metamodel doesn't carry an aggregation flag on Property.

We plan to address the is_id and multiplicity (for attributes) gaps. If you'd like to contribute a fix for any of these, PRs are welcome!

Regarding testing your generator via the API, the approach you showed in Edit 2 using class_buml_to_json() +requests.post() is a good way to do it.

We have created a documentation for the WME, but if you feel we should explain more part dont hesitate we will be happy to update it !

[miloss01]

Are there any more limitations regarding class dieagram except those in table?

[ivan-alfonso]

These are basically the main limitations for now. Just to clarify, they only affect the JSON side, which is the intermediate format used by the Web Modeling Editor (WME).

As Armen mentioned, everything in the table is supported in the B-UML (DomainModel), but not fully handled yet in the editor/converters, so some things get lost in the JSON ↔ B-UML round-trip:

• Property.is_id → not serialized
• Property.is_read_only → not handled
• Attribute multiplicity → not supported
• Aggregation → converted to normal associations