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.
Related
or "How to decouple UI from business logic in Delphi?"
Each target platform has its own set of native firemonkey controls (Windows=VCL, MacOS=TMS mCL, Android=D.P.F, iOS=TMS iCL and D.P.F). The new FireUI (multi-device form designer) is a great solution for styled components, but not for native components because it still requires the same component on the master pane to support all platforms. As you cannot mix them on the same form, it completely breaks the whole idea with Delphi.
A lot of developers would say that Delphi is the broken approach, see "Why FireMonkey is so fundamentally wrong in every aspect". However, the premise for this question is NOT to argue against Delphi, but to get the best results out of what it does offer.
The conclusion is then that for each form in your application you have to make a separate form for each target platform. This leads to these questions:
Challenge 1: How to include different form files in your project depending on your target platform?
Solution 1: include all of them, i.e. MainForm_IOS.pas, MainForm_Android.pas, MainForm_Win, MainForm_OSX.pas, and then use compiler directives inside the files, so only the content of one of the files is active. Disadvantage: a large application can have many forms (we have around 40), so we are talking about a large number of included files.
Solution 2: Do not include them in the project, but instead just place them in seperate folders. Then you can add the matching folder to the search path for each target platform. Disadvantage: They will not show up in the Project Manager, so it will slow down the workflow every time you need to find a file.
Solution 3: Create a project for each target platform. Disadvantage: Every time you add new units or change common project settings you have to (remember to) apply it to all projects.
Update: As suggested in the Malcom Groves video, placing all the business logic in a package will remove the disadvantage from Solution 3. So I consider solution 3 as the best approach.
Challenge 2: How to connect the different device forms to the (same) business logic?
Possible solution: Create a "Helper" class that contains all the code you would normally have in the form unit.
Update: This "Helper class" is actually what the MVVM calls a ViewModel. What I need seem to be a MVVM framework that can support the databinding. I have made another question about that.
Any input and suggestions about best practice are welcome.
For challenge 1:
You can conditionally link in your FireMonkey form resources depending on the compile target:
{$R *.Windows.fmx MSWINDOWS}
{$R *.Macintosh.fmx _MACOS}
etc.
This is excatly what the XE7 Multiview designer does, but I see nothing against using this mechanism to link whole form files conditionally in to your executable. Of course you might also want to ifdef the corresponding units in your project file.
For challenge 2: Just use some form of Model View Controler logic. So your platform dependant forms will talk to a platform independant controler.
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'm investigating Adobe CQ5 and would like any advice on how to integrate its drag-and-drop UI to create a responsive website. It seems as if it works on a concept of fairly bland templates with components that can be dropped in pretty much anywhere, including things like "three-column control" - which would make designing a responsive grid structure very hard (as it would be hard to prevent users from dropping in a control that could ruin the layout).
Does anyone have any experience or advice on this? I'm really looking for deep technical details on the structure of templates vs components (paragraphs), and where/how to manage to the CSS.
CQ5 offers ways to control what can be done within a template, so thinking that components "can be dropped in pretty much anywhere" may be misleading. Page templates are designed and configured so that you control which components can be added to a certain area of a page. This allows you to only make those components available that will work with the template layout, excluding components that would wreck the layout. Then authors are only allowed to use things that will work. If they attempt to drag a component onto a paragraph (parsys) where that component has not been configured as available, the UI will not allow them to use it there. So CQ actually makes it easy to prevent users from dropping a control somewhere that would ruin the layout.
This is outlined a bit here:
http://dev.day.com/docs/en/cq/current/howto/components_develop.html#Adding%20a%20new%20component%20to%20the%20paragraph%20system%20%28design%20%20%20%20%20mode%29 which states that
"The components can be activated (or deactivated) to determine which
are offered to the author when editing a page."
When it comes to CSS and JavaScript, you can create a client library and then include the relevant client library on the page. Backend CQ functionality will take care of combining multiple CSS (or JavaScript) files into a single minified file to allow for a single HTTP request of an optimized file. This it outlined a bit here:
http://dev.day.com/docs/en/cq/current/developing/widgets.html#Including%20the%20Client-Sided%20Code%20in%20a%20Page as well as
http://dev.day.com/docs/en/cq/current/howto/taglib.html#%3Ccq:includeClientLib%3E
So you might develop several components that share a client library, then when any of the components is added to a paragraph the client library will be included on the page. You may also want a CSS library that applies to all the templates to give a common look and feel, yet allow components to add their own when they are used.
These guidelines for using templates and components outline how you provide control, yet flexibility:
http://dev.day.com/docs/en/cq/5-5/developing/developing_guidelines_bestpractices.html#Guidelines%20for%20Using%20Templates%20and%20Components
I'll document our successful WIP experience with RWD and CQ5
Assumptions:
A well documented style guide.
Our First Steps:
Modified existing column control component css to utilize twitter bootstrap grid css.
Create a base page property allowing two different classes on the grid container to be set and inherited by child pages. (container||container-fluid).
Leverage out-of-the-box components where ever possible.
All component widths inherit the width of their parent container allowing for components to be dropped into any location within a template.
Issues:
The out-of-the-box column control component can not be nested.
We are looking into building a custom column control component.
Takeaways: this is an evolutionary project and we are constantly iterating.
With the recent launch of AEM 6.0, they have an example website called as Geomatrixx Media. This website is responsive.
You can take this example as reference and start building on top of it.
I have a website that has related pages. They have links that point back and forth to one another but I have no integrated system, nor do I know what that would mean.
What is the minimum code that a group of web pages must have to be considered a Content Management System (CMS). Is it that all the settings are in the database and the pages are generated somehow? Is there some small snippet that all my pages could share that makes them a CMS, database or not?
Thanks. I was also hoping not to have to study a giant CMS to see what makes it a CMS . After maybe a basic understanding I would know what I was looking for.
edit: here's why I ask about code. Whenever I have looked at a CMS, and maybe they aren't all the same, I saw that to develop a module you always had to inherit from certain classes and had some necessary code. I didn't know if there was some magic model that I just don't get that all cms makers understand.
edit: perhaps my question is more about being extendable or pluggable. What would a minimum look like? Is it possible to show that here?
edit: how about this? Is something a CMS if it is not extendable and/or pluggable?
I think this is really impossible to say. We all manage content. The "system" is just whatever mechanism you use to do so(dragging and dropping in Explorer or committing content changes via a SQL query). To say there is a minimum amount of code needed really isn't indicative. What is indicative is how often you find yourself making mistakes and how easy it is for a given user of a given skill level and knowledge to execute the functions in the designed system. That tells you the quality/degree of what you have in place being worthy of being called a "CMS."
Simply put a CMS is an application that allows the user to publish and edit existing web content.
In response to the edit:
A "good" CMS allows of extensibility. By using inheritence you can extend the functionality of a CMS outside of the core components provided. That's the magic.
About Extensibility:
Depending on the language/framework you want to build your CMS with, you can load pages or controls(ASP.NET) using command built into the framework. Typically what is being done is a parent class/interface is being defined that forces an module that is to be developed to follow some given standards:
Public MustInherit Class CMSModule
'Here you will define properties and functions that need to be global to all modules being developed to extend your CMS.
public property ModuleName as string
End Class
public class PlugInFooCMSPage
inherits CMSModule
end class
Then it's just a matter of simply loading a module dynamically in whatever construct a given language/framework provides.
Ultimately, a CMS is a system that lets you manage content, so it needs an user interface that is dedicated to letting you easily create, edit and delete pages on your website.
However, it's fairly usual to expect from a CMS to provide a browser-based WYSIWYG page editor, file uploading, image resizing, url rewriting, page categories and tags, user accounts (editor, moderator, administrator), and some kind of templae system.
Without dragging you into a theoretical explanation of what a CMS is and what it's not, perhaps some tutorials on the building methodology of a CMS will help you better understand.
http://css-tricks.com/php-for-beginners-building-your-first-simple-cms/
http://www.intranetjournal.com/php-cms/
A Content Management System is a System that Manages Content. :)
So if you got many pages that share the same layout, you can create a system that stores the content into a database and when a page is requested, it gets that content, merges it with a template that contains the page header, menu, etc.. and outputs the result.
The basis idea is that you don't want to copy HTML pages, and have to edit hundreds of them when you want to change your layout.
Such a system can be very complex, featuring wysiwyg editors, toolbars, version control, multiple user publishing and much more, but it could be as simple as a single page behind a standard loging, that contains only an input field for the title and a textarea in which you type the html content.
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... ;)