style and script

[IamPersistent]

The ProductBundle has finally reached a point that it has some real world usefulness and there are a couple of bundles that are reaching that state. Even though the primary objective of Vespolina is to provide bundles that can be used independently of the Vespolina project, it would seem from some of the feedback, that it would help with adoption rate to have something that can be use. I think if we improve the interfaces for product entry (which is also getting ready to include pre-building option groups) and have that ready to use in the sandbox, it will help people get their feet wet with Vespolina.

I've struggled in my mind with keeping the javascript and any css agnostic, but I'm thinking more that it really doesn't matter. Someone who doesn't want the default interface is going to build their own, so what we use or don't use will probably not matter. Also, if we keep javascript and css limited to the sandbox and not the actual bundles, (just use simple templates in the bundle), then it doesn't matter anyway. A problem I could see happening with that is it might lead to some confusion when the Bundles behave differently in a non sandbox environment.

I'm proposing that we use jquery and twitter bootstrap http://twitter.github.com/bootstrap/ to build a more friendly interface. I'd love to get feedback on using these libraries and if we should place them in the bundles or sandbox.

Richard

[Luis Cordova]

i just spent a long week integrating well twitterbootstrap.

By all means the use have to be taking into accout mopa bundle. None
other. We have to avoid NIH in this regard and also do not reinvent
the wheel but rather make room for bundles like this. Allow
integration, but also leave room for other. So we can use mopabundle
without problems. It has been bullet proof in a week of frustration.

I will try to work pull the sandbox and add this bundle and push back
to see how far we go.

Thanks Richard,

Luis

[Luis Cordova]

done :

https://github.com/vespolina/vespolina-sandbox/pull/41

[Daniel Kucharski]

To start, great job on the product bundle!

1)Place of UI coding

We never said that the UI should be part of the individual bundles.
For me these individual bundles should only contain the domain
objects, managers, persistence, common business entities and business
rules. We would thus provide an API and allow UI's to connect through
REST services.

If it is really required to have an UI per bundles, they can be simple
CRUD based admin pages that to do basic operations. But i think that
people would in the end throw the bundle UI away and use their own.
It's only when you combine different bundles that a UI makes sense
(eg. a sales order, product and customer bundle are needed to build a
sexy sales order entry UI)

So yes I would have one centralized place for the UI. However i'm not
sure it would need to be in the sandbox. Why not just move it into a
VespolinaUIBundle?

2)Javascript library

Any specific reasons you choose this one? I'm a bit fed up about the
existing of soo many javascript libraries that i honestly can't choose
anymore.
I've had a quick look to twitter bootstrap and it looks fine, although
I wasn't seeing any advanced UI components which http://www.sencha.com/products/extjs/
providues such as complex data grid.

On Nov 26, 9:54 pm, IamPersistent <iampersist...@gmail.com> wrote:
> The ProductBundle has finally reached a point that it has some real world
> usefulness and there are a couple of bundles that are reaching that state.
> Even though the primary objective of Vespolina is to provide bundles that
> can be used independently of the Vespolina project, it would seem from some
> of the feedback, that it would help with adoption rate to have something
> that can be use. I think if we improve the interfaces for product entry
> (which is also getting ready to include pre-building option groups) and
> have that ready to use in the sandbox, it will help people get their feet
> wet with Vespolina.
>
> I've struggled in my mind with keeping the javascript and any css agnostic,
> but I'm thinking more that it really doesn't matter. Someone who doesn't
> want the default interface is going to build their own, so what we use or
> don't use will probably not matter. Also, if we keep javascript and css
> limited to the sandbox and not the actual bundles, (just use simple
> templates in the bundle), then it doesn't matter anyway. A problem I could
> see happening with that is it might lead to some confusion when the Bundles
> behave differently in a non sandbox environment.
>

> I'm proposing that we use jquery and twitter bootstraphttp://twitter.github.com/bootstrap/to build a more friendly interface.

[Richard Shank]

On Sat, Nov 26, 2011 at 10:49 PM, Daniel Kucharski <dan...@xerias.be> wrote:

To start, great job on the product bundle!

1)Place of UI coding

We never said that the UI should be part of the individual bundles.
For me these individual bundles should only contain the domain
objects, managers, persistence, common business entities and business
rules.  We would thus provide an API and allow UI's to connect through
REST services.

I don't have a problem with having RESTful interfaces, but I'm talking about making it easy for people to start using the bundles. I think the easier it is to get started, the greater the chance of people using the bundle. If its just an API, I have to build out something, just to test it out.

Controllers and views are part of Bundles so, its not unreasonable to expect that to be there. Much of what you are saying should be the only things in the bundle, could actually be moved into a library (and maybe should be).

If it is really required to have an UI per bundles, they can be simple
CRUD based admin pages that to do basic operations.  

Its not as simple as it might seem. In a product you have options that must be grouped together (colors have choices of red,blue,green, sizes of small, medium, large) This is not an extreme case and to do this, collections form types are required. I do not know of a way to add additional fields to a collection form field w/o using javascript. We immediately move  beyond a simple CRUD with options, which are often a requirement of a product. I think it would be helpful to have the tools to use that immediately.
 

But i think that
people would in the end throw the bundle UI away and use their own.
It's only when you combine different bundles that a UI makes sense
(eg.  a sales order, product and customer bundle are needed to build a
sexy sales order entry UI)

I disagree with the idea UI only makes sense when combining bundles. If I wanted to just have a display of the products, w/o any type of commerce, I would still need to have a UI to enter the product data. I agree people may through away the UI, however, part of building things in an agile manner is only build what you need at the time. You look at the standard controller used in Symfony and its not the recommended long term for  a controller. You should only be injecting what you need, not the whole container. Why do we use it? Its a quick way to get started. Having usable forms and templates are a quick way to get started.

 

So yes I would have one centralized place for the UI.  However i'm not
sure it would need to be in the sandbox.  Why not just move it into a
VespolinaUIBundle?

Well the problem with a UI Bundle is you either would have to load it up with all of the controllers you need in every bundle or the individual bundles would have to render templates in the UIBundle. I don't like either approach. There may be something I'm missing here, but on the surface, it seems like a needless complication.

My reasoning for putting it in the sandbox is so if you don't want to use it, there's nothing in the Bundle forcing you. You are going to need an Application\Vespolina\XxxxxBundle either way, so putting it there keeps it separated from the Bundle, but puts the specifics of UI into the sandbox the way you would do it any way, in your own project.

On the other side, I could argue that the needed templates and javascript to do the minimal functionality of the bundle is a requirement to make the bundle function, so it could be considered part of the bundle. I don't like that idea, because then we are somewhat forcing a particular styling and javascript system from within the bundle.

2)Javascript library

Any specific reasons you choose this one?  I'm a bit fed up about the
existing of soo many javascript libraries that i honestly can't choose
anymore.
I've had a quick look to twitter bootstrap and it looks fine, although
I wasn't seeing any advanced UI components which http://www.sencha.com/products/extjs/
providues such as complex data grid.

I picked jQuery because most frontend and a lot of backend people are familiar enough with it to work with it. Personally, I don't have time to learn the particulars of another library and since i fall into that group that is familiar with jQuery, it made it easy to choose.

Bootstrap is not meant to be complex, its a way to quickly prototype something and still look usable to the average person.  As far as the data grid goes, if we want to go down the road of using data grid for admin of complex data, then I would rather use SonataAdminBundle. I'm finding that its helpful to lead people on what to do in entering data and a grid is not very helpful in that manner.

Bottom line, the more people that are using Vespolina, the quicker the project grows. At this point, I'm much more interested in getting something up that can be used than leaving something so open that you have to invest time and energy, learning the ins and outs, just to get started.

Richard

[Daniel Kucharski]

I think that we can give it a shot and tackle issues when they come
along.

But maybe we should do some UI sketches before coding everything?

[Tim Nagel]

Its my opinion that we adopt something like SonataAdminBundle for the default interfaces at this stage. IMO, its more important to get the functionality down, and not worry about picking interfaces and designs. (That and its already using jquery and twitter bootstrap, which I agree with Richard on)

Work can always be done in parallel for designing the interfaces but ultimately I dont think this matters yet.

t

[Luis Cordova]

simple answers

I say we just move on with this. What we have discussed has been
already solved on symfony2, no need for spending time on this. We will
have override power, and simplicity, no work on sketches, work in
sketches if you want to make your own, Sonata already uses bootstrap
templates, so yes grid, and yet exposes some configuration and at the
same time overriding, we can later make a UI bundle aka themeBundle.
The idea is to lightly move along.

Mopa in the midst of everything is the best to me. I have selected it,
tried and read others, discarded all but this. We can throw it or
adapt it if we need. It will just adapt.

wait for my PR on ProductBundle, two line change or something, and the
sf2 way since it inherits from base anyway. If it it doesn't then it
does not make much sense since it will be overridden anyway.

[Luis Cordova]

agree with ozmerk et al
let's this don't distract, this is just a temp mopa use for the
sandbox, i was thinking the same for SAB use.