TYPO3 is kind of new to me, but what I try (need) to implement is a multi-step-Wizard without a form, just a few buttons which lead to other buttons which then lead to specific pages. It should contain a back button and a step-indicator.
I first started to use html with vanilla JS but since the Wizard should support multi language I am a bit confused. Could it be better done with a own Extension? Use the Controller with Fluid?
Can you give me any tips on how I could tackle the problem in a good, TYPO3 manner way?
I tried it with vanilla JS and many if-else conditions. If button1 was clicked, set its style to none; and set the style of button2 to block; etc.
I tried it with a controller passing all the wizzard data to the view, use fluid to iterate and generate buttons.
But nothing seems to be a good solution. It all ends up with a bunch of DRY and hacky code.
Pretty much sounds like a "tab" element to me. You could go for the official introduction package or maybe the bootstrap package, that is the base for the introduction package.
https://extensions.typo3.org/extension/introduction
https://extensions.typo3.org/extension/bootstrap_package
With these packages as a base, you could easily implement something like this:
https://getbootstrap.com/docs/5.0/components/navs-tabs/#javascript-behavior
As you want that wizard in front end it is no specific TYPO3 problem.
There are elements in TYPO3 which are called 'wizard'. But that are forms to get some information to fill in a normal back end form field. That has nothing to do with the front end and the wizard you want.
For your solution it is necessary to analyse your requirements.
First: is the decision tree fix or may it vary sometime?
Second: how many decision levels do you have? how many endpoints do you have?
A small fix tree can be hardcoded.
If you expect changes or have lot of levels it might be better to have a flexible solution which gets called recursively.
This might include a hierarchical data structure to represent the decisions until you get an end point with an url to the final page.
The answer to the question about the amount of decisions might change the implementation:
If you only have a few decisions all data might be stored in the initial page and javascript only changes visibility or content of elements.
If you have a lot of data you might consider AJAX to get only small parts of data for the next decision from the server. repeating until you reach an end point with a final url.
In general:
have a data structure with something like:
ID
title/question
option1-text
option1-url / next node-ID
option2-text
option2-url / next node-ID
:
Related
I'm trying to create subpanel in Account detail view where list of elements is fetched from external REST service.
I know how to define subpanel, but have no idea how to fill it with data from external network source. Was trying to use get_subpanel_data but there I can only change SQL.
Any ideas how can I do this?
When I've done this in the the past, at least with Sugar 6, I opted distinctly not to try to create a true subpanel. The data being loaded is coming from an outside source and is loaded dynamically with the page, so why present it as if it's static data coming from Sugar? Instead, I created a custom Smarty template to use as the footer on the detail page. For such an example, you can check how it works on the Calls Edit View. I think it's the footerTpl parameter in the detailviewdefs.php or editviewdefs.php. I loaded the smarty template by creating a custom detail view for my module, so custom/modules/MyModule/views/view.detail.php - extend the base Detail View class and override the display to feed Smarty new params, then your Smarty template only needs to iterate through and present the data that your view defined.
To be super-hip and abide by MVC, you could even put your custom code into your bean (if it's a custom module) or into a custom controller method, then reference that from the view.detail.php, and still feed it from there to the Smarty template.
Alternatively, you could just load JavaScript into the Smarty template and use the JavaScript to call the third-party service, parse and present it, etc.
I realize this question is a little bit old now however it comes up fairly often so why not provide an answer with a couple possible solutions. I won't get into code but more just into the design theory of how it can work. If someone needs more specific code help then that is another question.
A couple ideas...
As you mentioned you can define a custom Function which will load in Data to the SubPanel from your own SQL Query. That is one method that I just recently got to finally put to use after knowing about it for a good year and a half.
When you go this route, you are restrained to using the Columns in the SubPanel. I assume it is using the actual Metadata files to determine which Field Columns a SubPanel can use so you pretty much need your custom data in a Database table to have the same column names as the fields defined in the SubPanel Metadata.
Obviously this works great in the right situation, however not always and that leads us into the 2nd method I know of.
The other way is pretty much what #Mattew-Poer mentioned in his answer. It means abandoning the SubPanel altogether and instead generating your own HTML. This is by far my favorite and prefered way of doing it and I have been some really custom modules due to this being possible in a custom module! I will show an example below.
(Click HERE to View full size image)
In the screenshot, you can see in this example that I have something looking Similar to a SubPanel however it is not and is much for flexible and easy to customize.
Example, to the far left column in my fake subpanel is image checkboxes. When clicked on, an AJAX request is made to change the Task row Status.
After that, the checkbox image is updated to indicate the new Status state, the Modified DateTime is updated, the Status column has color background SPANS and is also updated with the correct text and background color when the left side checkbox is clicked.
Doing any of this with the standard SubPanels is a complete nightmare and would be difficult to do some of the stuff that you are open to do when you build your own version of a SubPanel.
With that said, I have built an identical clone of the above screenshot using SugarCRM default SubPanels! It was a nightmare. I could easily update the content and HTML in some of the columns. I even had the AJAX click checkbox image to update and do all the other updates I mentioned above. It wasn't too hard and worked fairly good but it had some issues.
When you do inline edit, inline create record, or subpanel paging to load different set of record. You would then lose all the custom HTML formatting that was applied. The reason is, in the SubPanel you are limited to using the After UI load logic hook. So since the "Page" is loaded already, when an AJAX request is made to add/edit the subpanel content or load a new set of items with the paging links. It only loads the SubPanel content on those events and the whole Page content does not reload. Because the logic hook only fires off 1 time after the page loads, this newly loaded subpanel data doe not receive any of your custom HTML formatting.
In my case, this means that nice looking colored background Status spans are lost, the image checkboxes are lost, and some other functionality is lost.
Now to get super technical, I could have gone another 3rd route and instead made new Custom Field Types for each SubPanel filed that I needed to apply custom HTML to. This process is super hard in my experience and in some cases it really isn't the BEST solution.
Because of the reason explained, this is why my new modules use the Custom HTML route to generate my own version of a custom subpanel or whatever Data is needed in my Module pages! So far it is working better than I imagined and has opened doors for me to build custom SugarCRM modules that I previously didn't even realize would be possible to build due to some of the issues I mentioned above. Now I bypass them altogether and open the door to do pretty much anything!
I've got some really cool stuff for SugarCRM in the works right now. If anyone has any questions feel free to ask in a new question or for me personally in a comment here.
I am attempting to build a simple application using wicket and have been impressed so far. I have been taking advantage of the Component class to determine behavior of elements on the page based on user input or the model. I see the component model similarities with JSF, but find the wicket lifecycle easier to manage.
What i haven't been able to understand is having to add every component to the tree for every wicket:id mentioned on a page, especially for ones without any children. it seems heavy handed to have to build up the tree in java code when the tree has already been somewhat defined within the markup. what am i missing?
edit
I should probably give an example. I have a label for an input box that in some cases i want to be able to modify. 95% of the time the text and attributes i have for the label in markup will be fine.
Short answer: Yes, you have to add them.
Long answer: You can create custom code to do this, but I doubt it's worth the effort.
With JSF, you use a non-html tag, which has one component type associated to it - for example, h:inputText correspond to the class HtmlInputText -, so it knows what class to instantiate.
With Wicket, the HTML file contains only (with a few exceptions) HTML tags, and you have to instantiate a concrete component for each wicket:id-marked tag you add to the markup, because it can't know for sure if <span wicket:id='xyz'> means a Label, a FeedbackPanel, a WebMarkupContainer, or some custom component.
With JSF you do in the markup what, with Wicket, you do in Java code, that is, to build the component tree, bind components to properties, and handle events. It keeps everything in one file (you don't have to create a class for every template file), which has many, many cons (some may think it has some pros, I digress).
You page is never just a simple form that does nothing. You want to convert and validate the input, you want to process the submit, you want to update components using Ajax. With JSF, you do all that in the (non-compilable, type-unsafe, poorly tooled, non-refactorable) template, making it bloated with expressions, configuration tags, and - gawd forbid - business logic.
If Wicket had support for this (and, for the matter, it has the flexibility needed for you to build this add-on yourself), you would have to add lots of extra annotations (special, non-standard tags and attributes) to the markup, to declare what class to instantiate, what model to update, what validations to execute, etc., compromising two of the beauties of the framework, the clean HTML template, and the clear separation between visuals and logic.
One framework that tries to do more in the template, while remaining less bloated than JSF (which isn't that hard anyway) is Apache Tapestry. But as can be seen in its tutorial, you still end up having to use non-standard tags and following arbitrary conventions to bind the template to the code (you may like it, but if this is the case you have baaad taste, sorry :P).
I have a label for an input box that in some cases i want to be able to modify. 95% of the time the text and attributes i have for the label in markup will be fine.
You could try to wrap the content of the label in a Model, enclose that label in a container and repaint the container (target.add(container);).
Offcurse you should add them.One of the most powerful facilities of wicket is that allow you to make a reusable components espacially html components.
There are a million ways to build a house, but most people wouldn’t
consider building toilets, bathtubs, and glass windows from scratch.
Why build a toilet yourself when you can buy one for less money than
it would cost you to construct it, and when it’s unlikely you’ll
produce a better one than you can get in a shop? In the same fashion,
most software engineers try to reuse software modules. “Make or buy”
decisions encompass more than whether a module is available;
generally, reusing software modules is cheaper and leads to more
robust systems. Reusing software also means you don’t have to code the
same functionality over and over again.(wicket in action:manning)
So to have a reusable wicket pages, wicket just needs a html page to show it's components hierarchy or their positions. The types and model of these components left to programmer.
I could not find a wicket tag like wicket:include? Can anyone suggest me anything? I want to include/inject raw source into html files? If there is no such utility, any suggestions to develop it?
update
i am looking for sth like jsp:include. this inclusion is expected to be handled on the server side.
To do this, you'll need to implement your own IComponentResolver.
This blog article shows an example somewhat resembling what you're after.
Is it raw markup that you want to include, or Wicket content?
If it's raw markup, even a simple Label can do that for you. If you call setEscapeModelStrings( false), the string value of the model will be copied straight in the markup. (Watch out for potential XSS attacks though.)
"Including" Wicket markup is done via Panels (or occasionally Fragments)
Update: If you add more detail about the actual problem you need to solve, there's a good chance that we can find a more "wickety" solution, after all, JSP and Wicket are two different worlds and the mindset of one doesn't work very well in the other.
I am almost at the end of my rope trying to style my Zend form using decorators. Previously to avoid these issues I would create a form script extending zend_form, add whatever validators, labels, etc I needed then retrieved the element from my view script using $form->getElement('my_form_element');
that way I could wrap whatever css tags I wanted around the element. I thought I should learn how to use the built in decorators, but I'm starting to feel like it's a waste of my time. My old way seems easier, is there some reason I am not seeing that makes using custom decorators better?
In general decorators are used to dynamically add functionality without having to touch the code's core functionality and for a better re-usage of code. In Zend_Form however, I think that the decorator system (as well as Zend_Form in general) is unintuitive and heavily over-engineered and so it does exactly the opposite of what it should do: Help the developer to create better and more intuitive code faster.
In my opinion the usage of Zend_Form_Decorator makes only sense in the case where you have some extended logic that you plan to reuse throughout your project on multiple and different types of elements.
Let me give you two examples:
You want to add a tooltip icon next to an arbitrary form element with a nice icon and a fancy JavaScript hover box.
An element should be validated directly upon entering data by posting an AJAX request and adding either a green check mark on success or a red cross icon on failure next to the element.
With the decorator you can now separate the logic of the added functionality from that of the underlying element and so you can use the same code to add the tooltip and/or the live validation feature to a textbox element as well as any other element simply by adding all the decorators you want to the element.
There is also a great article from Matthew Weier O'Phinney, the lead developer of Zend Framwork, that gives some background insight on the motivations for using decorators along with a lot of examples: Decorators with Zend_Form
Decorators can come in handy if you have a specific repeatable markup for your forms, for example if you want to use Bootstrap. Other than that, especially if you have a good html/css person, I would avoid them.
I am looking for a nice framework for developing a GUI builder Application. We have an application where 100Os of custom data entry forms and their print formats are required and each client will need some modifications on these. We have a developed a product using java based open source templatnig frameworks so that the layout and field definition are stored in database and rendered dynamically to the user. We also have an appication to design these forms but cannot do visual design.
Now I am trying to make a Visual Form Designer application for generating these forms. Can any one suggest some open source frameworks than can be used? Can I use Eclipse Visual Editor? Or is it better to develop some kind of parser for HTML using AntLR and then parse the HTML output from already existing GUI builders like Dreamweaver to get the desired output?
Thanks and Regards,
-- Kannan
Oooh, great question!
I wouldn't know any readily availble framework that you can use. Depending on your needs however, I think rolling your own shouldn't be too hard.
First of all, you probably wouldn't want to give the users too much freedom. Freedom only gives them the opportunity to mess things up and make the resultant forms hard to use. I think from your description that the fields are pre-defined, so that the user only needs to customize which fields appear on a given form, and in what order. Order can be a simple thing like top-to-bottom. Some semi-intelligent automatic layouting could be used to conserve screen space. Adding a feature to group fields together would probably also be useful, and grouping would lead to some kind of standard "group" widget.
Accepting simplified functionality like this, you don't really need the flexibility of a full gui editor. A couple of listviews, maybe a property sheet and a preview window will be enough to give your users the functionality they need.
Of course, this only holds for screen forms. Print forms may be trickier to layout, as people may want to cram as many fields as possible into very little space so the entire form can fit on a single page or something. I really don't have any suggestions for you there, but maybe a similar "simplified" approach with some intelligent auto-layouting could work.
Overall, my advice would be: Keep It Simple! (S... ;)