Actually, Joomlacode does have a non-edit view, if you aren't logged in to the site. I'm kinda curious what the default is if you're logged in and not registered to the project (i.e. what fields are available to them).

Leaving the default non-editable view is probably a good idea for the non-logged in folks (less to worry about security wise I think). We can let the router handle the routing to edit versus default, or even the edit controller task (implied task to get that one written) could figure that out for us.

What I meant was: Use the same view for view and edit.
Depending on the users permission either a select box / text input is displayed when he/she has the permission to edit, or just the plain text for simple viewing.
Same goes for the save button ;)

Maybe that doesn't make much sense and only complicates things, just an idea.

What I would like to set up as soon as possible is a view to actually "submit a new issue". Along with the list view, I think this will be one of the parts that we need to think about "soonish".

I mean I would love to bring it online by tomorrow morning :)

Oh, and if we allow non registered folks to submit issues and comment we won't need a non edit view at all..

If you look at my repo, I have a branch started on the edit view. My plan
is to just have a link on the detail view, and if the user is logged in
with the proper group level, an edit link will be displayed. I've been
plugging away at the edit view and thinking about how best to handle the
"extra fields". Im wondering if I should go to more of a "k2 extra field"
system, so that extra fields will just be able to be looped through in
code. I'm trying to avoid writing any specific queries.

Once I get something working Ill merge it to the jtracker repo, for now if
you want to fork my branch and take a look at what I've got, feel free!

On Sunday, October 14, 2012, Nikolai Plath wrote:

What I meant was: Use the same view for view and edit.
Depending on the users permission either a select box / text input is
displayed when he/she has the permission to edit, or just the plain text
for simple viewing.
Same goes for the save button ;)

Maybe that doesn't make much sense and only complicates things, just an
idea.

What I would like to set up as soon as possible is a view to actually
"submit a new issue". Along with the list view, I think this will be one of
the parts that we need to think about "soonish".

I mean I would love to bring it online by tomorrow morning :)

Oh, and if we allow non registered folks to submit issues and comment we
won't need a non edit view at all..

—
Reply to this email directly or view it on GitHubhttps://github.com/JTracker/jissues/issues/20#issuecomment-9429538.

Regards,
Chad Windnagle
Fight SOPA https://www.google.com/landing/takeaction/

I've implemented a backend view that was used as a view/edit type situation, and I think it's more of a headache to do than what it's worth using JForm (in my getForm method, I had to conditionally disable basically everything, and still have some conditionals in the actual view and template).

The issue view can have two layouts; default and edit. Like I said before, we can let the controller conditionally route to the appropriate layout (is the user a guest; if so, give them the default layout). It's also a bit lighter on what type of framework processing and media resources we have to call upon.

OK so let's just scratch this idea, unless we have a lot of duplicated code ;)

@drmmr763 I wasn't aware of your branch (but I will follow your activities more closely).
Great that you have started the edit view. I don't know about K2, but SOBI or Kandanda comes to my mind when thinking about those fields - or JForm..
I tried to implement something flexible using categories and com_categories.
Looping over those fields looks like this in a view template: com_tracker/view/issue/tmpl/fields.php
The lists are build here: com_tracker/view/issue/html.php
And a multi purpose HTML selector class that displays those thingies: libraries/tracker/html/projects.php
So let's see if we can build something useful ;)

@mbabker I believe we also might need some sort of access check in the views since it is possible to access them with &view=viewname without any controller being involved..

So, OK let's go with different views.

Closing ;)

Just need something like this (https://github.com/joomla/joomla-cms/blob/master/components/com_content/views/form/view.html.php#L40) or check if the user's logged in (done that in another project). Permissions check is covered.

As far as the form fields, there's a reason I used the message I did when I pulled them out of the read-only view; quick reference. If we wanted, we could actually go in and have the edit view in the main branch now so this code doesn't get lost (just a matter of copying the view or layout, depending on which route we go), and that gives everyone a playground to mess with the com_categories implementation (which I think is actually a better use of "categories" over how it's handled in the CMS, now if we could just uncouple all the other display garbage too ).