Discussed with Jeffrey directly, the wizard helper is only meant for the backoffice. In the portal, there is the "portal form handler" which can be used to interact with object forms but is not a supported API, it is subject to change.
Cheers,
Guillaume
👍
2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just wanted to share I experimented a lot with this the past few days; the Wizard Helper is a great tool in the console, I managed to get it working for the purpose I needed in the front-end user portal as well 😁
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I wouldn't say a great tool... For example, handling of dependant fields is far too much complicated ! As iTop 3.1.0 will contain some objects form modification we might rewrite part of this code in the near future.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In that case it would be great to see a unified helper which works with both the console and user portal instead; and is able to send the "live"/actual values of the object being edited to the back-end where it can be transformed into an object to use in PHP server side handling :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@pgoiffon@glajarige is it already possible using this (portal) form handler to send the data to an endpoint and transform it into a (non saved) iTop object to work with; like the wizard helper can?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you can retrieve the values and send them to an endpoint of your choice. But to do that you might trigger the events on the form_handler with your own JS code.
Cheers,
Guillaume
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I already found out how to retrieve them; but I was wondering if there's also a more or less built-in method (or an example) of how to process all this data and get a "new" iTop object from it?
WIth the wizard helper, I'm able to post the "live" values from the front end to the back end and there's a function to create an iTop object from it built-in in the iTop core? That's the part I'm trying to find out now for the form handler :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Phew, completely unfamiliar with Symfony. Managed to finally get something working ont he server-side.
Could anyone give a quick hint on how to instantiate a container?
If I don't set a container for my ObjectFormManager, it crashes when calling OnUpdate() method. Reason: at some point a DeepClone() is called of the DBSearch that's expected to have been set on SelectObjectField, which is not the case without container.
As you are calling an endpoint (i guess), the proper way would be to declare your own route and the corresponding controller/action which will give access to the container automatically.
Check the approval brick it does the route / controller part for sure.
Then check in the ObjectController how the ObjectFormManager is used.
Hope it helps,
Guillaume
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm indeed calling an endpoint. I was just about to write that data/cache-demo-faq/portals/itop-portal-prod/srcProdProjectContainer.php also seems to get erased (probably after running setup), so it's also not possible to quickly rely on that :|
So I'll probably have to create a dedicated endpoint for the user portal, and indeed create a route and controller; and thenjust integrate my "traditional" endpoint? (which was based on what typical endpoints in the back-end look like)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yep, I don't know how your code logic is made, but ideally you should have it in a separate / independant service, then portal / backoffice endpoint would use it for their purpose /in their context.
Cheers,
Guillaume
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
Jeffrey I understand this is a project you are working on ? We are not doing such things so often, so if you're willing to share your code we would be very interested !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Pierre; it's part of the improvements I'm working on for my "Suggested articles/FAQs" extension.
This part is still work in progress; I was only used to the traditional endpoints (completely independent from the Symfony framework; or controllers and routes).
I actually have more similar use cases in mind; where I just want to capture the live/actual values of an object being created or edited in the end-user portal or console; and where I want to call an endpoint and use those live values for different purposes (typically to use the "new/updated" value in an OQL query, eg to select objects related to the new/updated value of the organization)
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was wondering if there's a counterpart to the "oWizardHelper" (console) in the user portal, while for instance creating a ticket?
Discussed with Jeffrey directly, the wizard helper is only meant for the backoffice. In the portal, there is the "portal form handler" which can be used to interact with object forms but is not a supported API, it is subject to change.
Cheers,
Guillaume
Just wanted to share I experimented a lot with this the past few days; the Wizard Helper is a great tool in the console, I managed to get it working for the purpose I needed in the front-end user portal as well 😁
Hello,
I wouldn't say a great tool... For example, handling of dependant fields is far too much complicated ! As iTop 3.1.0 will contain some objects form modification we might rewrite part of this code in the near future.
In that case it would be great to see a unified helper which works with both the console and user portal instead; and is able to send the "live"/actual values of the object being edited to the back-end where it can be transformed into an object to use in PHP server side handling :)
@pgoiffon @glajarige is it already possible using this (portal) form handler to send the data to an endpoint and transform it into a (non saved) iTop object to work with; like the wizard helper can?
I think you can retrieve the values and send them to an endpoint of your choice. But to do that you might trigger the events on the form_handler with your own JS code.
Cheers,
Guillaume
I already found out how to retrieve them; but I was wondering if there's also a more or less built-in method (or an example) of how to process all this data and get a "new" iTop object from it?
WIth the wizard helper, I'm able to post the "live" values from the front end to the back end and there's a function to create an iTop object from it built-in in the iTop core? That's the part I'm trying to find out now for the form handler :)
Phew, completely unfamiliar with Symfony. Managed to finally get something working ont he server-side.
Could anyone give a quick hint on how to instantiate a container?
If I don't set a container for my ObjectFormManager, it crashes when calling OnUpdate() method. Reason: at some point a DeepClone() is called of the DBSearch that's expected to have been set on SelectObjectField, which is not the case without container.
Right now I'm using something like
But those files seem to be randomly generated, so I suppose the same is true for the namespace?
Update
Think I have figured it out...
Last edit: Jeffrey Bostoen 2022-07-21
As you are calling an endpoint (i guess), the proper way would be to declare your own route and the corresponding controller/action which will give access to the container automatically.
Check the approval brick it does the route / controller part for sure.
Then check in the ObjectController how the ObjectFormManager is used.
Hope it helps,
Guillaume
I'm indeed calling an endpoint. I was just about to write that data/cache-demo-faq/portals/itop-portal-prod/srcProdProjectContainer.php also seems to get erased (probably after running setup), so it's also not possible to quickly rely on that :|
So I'll probably have to create a dedicated endpoint for the user portal, and indeed create a route and controller; and thenjust integrate my "traditional" endpoint? (which was based on what typical endpoints in the back-end look like)
Yep, I don't know how your code logic is made, but ideally you should have it in a separate / independant service, then portal / backoffice endpoint would use it for their purpose /in their context.
Cheers,
Guillaume
Hello,
Jeffrey I understand this is a project you are working on ? We are not doing such things so often, so if you're willing to share your code we would be very interested !
Hi Pierre; it's part of the improvements I'm working on for my "Suggested articles/FAQs" extension.
This part is still work in progress; I was only used to the traditional endpoints (completely independent from the Symfony framework; or controllers and routes).
I actually have more similar use cases in mind; where I just want to capture the live/actual values of an object being created or edited in the end-user portal or console; and where I want to call an endpoint and use those live values for different purposes (typically to use the "new/updated" value in an OQL query, eg to select objects related to the new/updated value of the organization)