This is a little vague, but I hope I'm allowed.
I'd like to get a feel for what the Magento developer community thinks of the Widgets API. Are they clear or confusing, useful or useless. The more detail the better. Do you use the feature? If not, why not? What don't you understand about the feature? etc. etc.
When I say Widgets, I'm referring the programatic APIs specific to the feature.
Yeah its definitely something we have wanted to take more of a look at but we haven't set any budget aside to actually investigate. I would love to create some little widgets that we could utilize for each client instead of having to create blocks that the client then has to pass data to inside of a static block. I looked into it about a year ago and just haven't looked back.
The funny thing is now there are a lot of widgets out there in the community, yet you still don't hear anything about them. I guess we just need more articles about them, which I am sure after you write one, we will all get it :). Basically people don't have time with how busy they are probably to investigate the Widget API fully enough to utilize it. And since there isn't a lot of knowledge base information about it, you don't see a lot of people using them.
I as a developer understand the usefulness of this API and it is not harder to use than any other thing in Magento. I have used it a lot cause I can understand the feature.
But me as the person who has to explain what is a widget or why I made something to be a widget, how should a user or designer use it, why there is a block and a widget side by side and what's the difference. Then I tend to think that this is a total disaster and we should have only widgets or only blocks or one common name and just some type/attribute/value that distinguish static and dynamic version of widgets so I could say : "Hey this block/widget you can drag or include wherever you like in your site and this one you can't"
I was excited about the widget feature when it came out. There is decent documentation available, and I was quickly able to code my own simple widgets. Since then, however, I never actually used widgets in my projects. I have never really understood when to use widgets, and I almost forgot about them.
I feel like we need articles and examples to show the usefulness of widgets. I need widgets to pop up in my head when a client asks for features that can be solved using widgets. Recently, a client wanted to have some text in the footer on the home page. I created a static block and declared it in layout/local.xml. With widgets, this could all have been done from the backend.
Related
Please Bear with me as I know It needs research from my side but still want to ask as It would make things a lot easier for me.
Here is what I want to implement.
An online shop where I would configure admin areas for different store owners (vendors). The store owner can belong to same area or different areas. Using the admin area, each store owner can select from pre-configured list of products and define prices for the products in different locations where they have a physical store. The end user can browse the products listing based on his location (area). If multiple vendors belong to same area as customer, the customer will see the product with multiple prices from different vendors. If none of the vendor configured the product of that area, customer will not see the product.
Now the question is, what would be the appropriate option for the above requirements.
Magento, Opencart, nopcommerce or something else?
This is based on my experience. My advice, if you want sth that goes beyond minor tweaks and a couple of new features, stay away from opencart for the time being.
First of all, you will have to pay (not little...) for extensions and mods of often low quality and crappy support. You should also feel lucky to find one that will cover all the features you want and interoperability between extensions is just non-existent. And if you ask for more features chances are you will have to pay again. There are some free extensions but most are a joke. Like, put a link in your footer or disable sth.
So your next option is coding. Opencart is easy to learn if you know basic php and you can start writing code fast. But.. Opencart lacks a solid mechanism for extending it (until v2.0 at least) and after a while it gets both chaotic and frustrating. Also, you will often need to implement stuff that needs some basic backend functionality from opencart but which is either offered in a way that is useless to you or with basic needed features absent. As a result you will find yourself creating your own "library" of functions that will allow you later to focus on your extension. Moreover there is actually no framework on which you can rely. Sure there are some functions and some methods that you can use, but that's it.
Another thing. The opencart community is not one of the easiest to go along with. I don't mean they are bad or that they will bite you, but people there try to make money and do not find it easy to share things with you, be it advice or code. Also, they are competitive. And they do not accept criticism, even suggestions, gladly. And there is a scent of eliticism in some threads that can upset your stomach.
This is how I have experienced opencart. I have to admit that I like opencart itself and I find pleasure in coding for it and even now I am debugging some new extension of mine. But often it reminds me that there is so much lacking and I often spend so much time doing trivial stuff that it makes me wonder if it is worth it.
I do not know about magento. It feels similar to opencart to me.
I would suggest drupal to anyone wanting to implement something custom. There is all a framework and powerful free as in speech extensions and a great truly foss community. There are a couple options there for building an eshop but I would go with the commerce module. It takes a while to get used to all the concepts but you can achieve what you want with just mere clicks. You won't even have to write code if you don't want to.
Again I repeat, avoid opencart if you need sth too custom (as you do). If not, opencart is one of the fastest to deploy.
I need a very lightweight discussion board for joomla 3.0. You should be able to enter a topic, name and message. I want people to be able to comment on the topics too. I do not want a full-fledged forum, just very basic.
The extensions I've found are all too advanced.
I'm thinking of two way to do this. Either by a custom form which submits an article in which comments are allowed, then i show them in a category listing. That would be great, but I'm not sure where to start to make that happen. I have some basic programming skills if needed.
The other way would be with a content creation extension I think? But since the ones I've looked at cost money I cant just test them and see if it works.
Any ideas?
A forum is definitely too heavy for what you need. You might be better off looking at the Blog category on the Joomla Extensions Directory. As you're using Joomla 3.0, you are a little more limited as to which extension you can use, however there are still a few:
Commercial:
EasyBlog
RSBlog
Non-Commerial:
CjBlog
JUBlog
As a second resourt, you could try using Komento
Hope this helps
I cant decide between this two options.
M Project vs Sproutcore
I'm building an application that will be primary served on mobile but has to be viable on desktop.
Mproject is on the edge with number and variability of his prebuilded widgets and may happen that I will need some more or at least alter some behavior.
So this is kind of down side of Mproject. But it looked for first review that Mproject need less code for basic stuff.
And the second problem comes with the skins. I will basicaly need reskin everything a lot. The design of app has to be very unique.
So I want to know which of them is easily to reskin not just by theme-roller and similar stuff.
I would appreciate any other JavaScript-only frameworks recommendations.
Thanks for all replies.
I'm not sure what kind of application are you building so you should take care with my answer.
M-Project solved our problems fine, and help us to make it clear code ... when you understand how it works. It requires a bit of hard work, the documentation is a bit poor and is a new project where some things are not yet implemented. You can change application look modifying HTML and CSS so I think you should have no problems with this.
Also you can download their code and modify it without problems, it is easy to read and modify if you need any specific behavior.
On other side, I never used Sproutcore, it have a really nice look. But documentation say it is focused on desktop applications. Probably you will not have too much problems to adapt the output HTML for mobile devices, I guess.
Lastly, I think you can take a look on Lungo.js Framework.
Best regards.
My team is tasked with quickly evaluating SproutCore and a couple of other alternatives. There's not really enough time for a deep dive, but our findings might let us convince the powers that be to allow for a deeper dive. (Right now, we're just taking a quick glance to see "what's out there").
So me and a teammate have started looking at SproutCore. I'm loving it so far, but he has already decided he doesn't like it. The reason he doesn't like it is he got the impression that the "data binding" in the Todos tutorial is the naive kind of data binding that a Visual Studio grid control might do ... where the widget itself is allowed to reach across the Internet to the server and obtain new data whenever it needs to paint itself.
I would be shocked if that were the case, because it is such a naive approach that really is only good for demo-ware, and SproutCore feels much more elegant than that to me.
Unfortunately, we're probably not going to have time for either one of us to find out for sure. So, can someone who has used SproutCore and knows it well please explain a bit about how Bindings work, and whether or not Bindings are allowed to initiate an Ajax call to the server to obtain more data?
UPDATE: I got the answers I need, partly from the google group and partly from digging deeper. The Bindings are exactly what I thought they were ... a great tool for connecting objects in memory inside the Javascript environment. They eliminate a TON of "glue code", and, like the rest of SproutCore, are REALLY well done. In no way is it anything close to "naive data binding". SproutCore is one powerful, elegant library, and I hope to get plenty of chances to use it (though my current project, alas, chose to go with something else).
I don't think I qualify as "knowing [SproutCore] well," but I don't think your question is really about bindings per se; it's about what's allowed to poll the server for data. It's my impression that bindings largely talk to each other inside the application. A binding can change data in the (local) Store, but I don't think the Store necessarily initiates an Ajax call every time it's changed.
ETA: This work in progress reiterates, "Bindings are used for inter-object communication."
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What comes first? After the design has been outlined and approved, should a designer create pages in HTML and then hand them to a developer to add code? Or should a developer build simple pages that work and hand them over to the designer?
I've always done the latter, but recently worked with a designer who built an entire site in HTML and handed it to me to make it work. I found it saves a lot of time for 3 reasons:
The developer doesn't have to create all the form fields and rudimentary layout.
The designer doesn't have to rework all the "ugly" pages into something attractive, instead starting with a clean site which is faster.
The code isn't accidentally broken by the designer. I've found designers are more likely to break the code doing their work than developers breaking the design adding the backend functionality.
In short, if the designer does his work first, there's very little rework. I just make what already looks great actually work.
So which is best practice? See other plusses and minuses?
EDIT: Assume both designers and developers are already in agreement on the proposed design.
Wireframe mockups and visual aides are a great way to elicit requirements from end users. Giving the user something to look at and see helps to drive the design to where it needs to go instead of developers just doing the guesswork.
Also, UI design does affect your code. I think the biggest myth that we buy into as programmers is that we can just build a business layer and then spread the UI on like peanut butter. It never happens this way, so I am a big fan of having designers work with users early on and often. Having a visual design to work against is like TDD for the UI, and it helps to drive the process downwards.
Best practice is to try it both ways, see which way works best for your organization, then do it that way.
Occasionally try it the other way to see if anything has changed.
That way you get a solution tailored to your situation without worrying about ephemeral transitory things like "best practice".
As you can probably tell, I'm not a big fan of rules being handed down from on-high. Don't get me wrong, if something proves to be an advantage, I'll use it (agile, for instance, since it focuses you on immediate deliverables). But it has to be proven in the environment you work in, otherwise it's just something that worked for someone else.
I think it depends highly on how your views and code behind are set up. Some people will put a lot of logic into their views and others will have little to none. It will eventually just come down to your specific case.
In most cases, I agree, it will be easier to create the HTML first and include the back end programming later. It is essentially making a specifications document for you.
Once you've got your storyboards all worked out and approved, it's probably more natural to do more detailed "sketching" at the HTML level first. But I guess I'd also try to decouple the design and code as much as possible, so that the developer and designer can work somewhat in parallel. Two ways of decoupling are XHTML/CSS and "unobtrusive Javascript".
The developer and designer can work out the skeletal XHTML page structures they'll need from the set of storyboards. The designer then can use static mock pages to develop the CSS style sheets and explore the artwork. Meanwhile the developer can focus on generating the XHTML structures without style information. The big advantage (and goal) of CSS was to separate page structure from page appearance.
Another avenue to explore are "unobtrusive Javascript" frameworks like jQuery, whose goal is to separate the page's behavior from its structure, again making it easier for the developer and designer to work in parallel. By parallelizing these activities, it would be possible to incrementally deliver versions of the final product, both in form and in substance.
I would definitely go with designer first. If the coder does the pages first, he's forcing a design on the designer -- particular for a multi-page form.
Depends on the type of place you work at and the skill set of your teams!!
I worked for a Design Agency for many years where designers ruled as they brought in the biggest revenue stream and the web work was an add on to the services.
We worked very closely with the designers to make sure the designs met requirements and we not to off spec. The designs were a lot of the time used as sign off (don't get me started!!) and not much could changed once agreed by the client. The designers were also not that good at HTML,JScript,CSS etc so this was left to the developers to implement.
So in this case design was always done first which worked well, even if it was for the wrong reasons.
Well, assuming that the designer produces high-quality HTML and CSS (which is far from obvious, btw), the question boils down to: do you have 100% control of your HTML or not?
If you use a CMS, or a framework that likes to produce lots of its own HTML (like ASP.NET), then you have no choice. Trying to make the output match the designer's HTML is a pointless headache. You'll be better off with your original method.
However, if you produce all of the HTML by yourself (using PHP or, say, a lightweight framework like Django), it's better for the designer to produce the HTML first, for the reasons you mentioned.
Small nitpick: I disagree with reason #2. CSS-based design is all about taking "ugly" (that is, bare and functional) pages and making them attractive, without even touching the HTML. If the developer writes decent, semantic markup, it should be pretty easy for the designer to add his design on top (well... with some HTML hacks added, like for round corners and the like), since this is what he should be doing in the first place.