Re: [Catalyst] Validating single arg id

[Matt Whipple]

Bill Moseley wrote:


I have a number of methods that start something like this:

sub view : Local Args(1) {
my ( $self, $c, $id ) = @_;

my $obj = $c->model( 'DB::Foo' )->find( $id )
   || return $c->res->status( 404 );

If $id is not valid then I might, as in that example, return with a 
404 status.


Of course, if $id is suppose to be an integer and a non-integer or an 
integer out of range is provided then the the database will throw an 
exception, which I want to prevent.  I want valid ids to return an 
object and *anything* else to return undef before hitting the database.


This is pretty low-level validation -- just validating primary key.  
For more complex validation I use a form validation module.


Obviously, I could do something like

return $c->res->status(404) unless $c->model('DB::Foo')->is_valid_id( 
$id )


in every method, but that's not very DRY.

What I've done in the past is override the find() or search() method 
in my model base class so that whatever $id is passed it is 
validated.  Specific model classes can override the is_valid_id()  
method if they use keys that are not a common key format (i.e. 
different integer range or non-integer key).


What's you approach to validating that $id in situations like this 
where there's a single id?


Do you just let the database throw the exception?  I prefer to return 
404s for invalid ids, regardless of their format (and likewise for ids 
that point to valid object, but are not owned by the current user 
instead of a 403).


I would probably avoid potentially hitting the database unnecessarily, 
and only use the exception in the case of complicated validation.  In 
the case of simple validation, why not something simple along the lines of:


sub some_action {
   my ($self, $c) = (shift, shift);
   #Get type checking out of the way
   my $id = check_id(shift, $c));
 
   #Continue on with apparently good data

};

sub check_id {
   my ($id, $c) = @_;
   $c->res->status(404) if ( !validate_id($id) );
   return $id;
};

sub validate_id {
   return 1 if looks_like_number(shift);
   return;
};  




--
Bill Moseley
mose...@hank.org 


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
  



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Problem with index.tt2

[Matt Whipple]

David Silva wrote:

Good Morning,

I already had set TEMPLATE_EXTENSION => '.tt2', and i solve the 
problem by changing the controller Root.pm like this:


sub index :Path :Args(0) {
my ( $self, $c ) = @_;

# Hello World
#$c->response->body( $c->welcome_message );
 $c->stash->{template} = 'index.tt2';
}
Doh...If you were getting the welcome screen it _would_ have been that 
line left over.  The other suggestions would have been in the case of an 
error screen. 

The book is referencing the fact that you don't need to set the template 
stash variable in this case, but explicitly specifying things is never a 
bad idea, especially when the default behavior is unclear or uncertain.  
Ironically the TEMPLATE_EXTENSION is irrelevant with the above setup. 


Thank you

2009/9/30 Matt Whipple <mailto:m...@mattwhipple.com>>


David Silva wrote:

Hi again,

I'm following the book "Catalyst - Accelerating Perl Web
Application Development" by Jonathan Rockway (2007) with
Catalyst 5.80013.

And in chapter 3 the autor says to create an index.tt2 page
and said that we don't need to do nothing cos Catalyst will
recognize the index. I start the server and it shows me the
default page of catalyst.

I'm following the book, so what i done wrong?

My guess would be that you haven't changed the template extension.
 See if index.tt <http://index.tt> works.  >From my recollection,
the book is building on top of the previous example and only
references some of the previously covered material rather than
explicitly going through it again (so also make sure you have the
view set up).

As a note, it's not that Catalyst "recognizes the index", it's
that the view defaults to trying to display a template matching
the present action (which in this case should be "index") with the
template extension appended.


Thanks once again!

-- 
David Silva - http://davidslv.com/





___
List: Catalyst@lists.scsys.co.uk
<mailto:Catalyst@lists.scsys.co.uk>
Listinfo:
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
 




___
List: Catalyst@lists.scsys.co.uk <mailto:Catalyst@lists.scsys.co.uk>
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/




--
David Silva - http://davidslv.com/


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
  



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Problem with index.tt2

[Matt Whipple]

David Silva wrote:

Hi again,

I'm following the book "Catalyst - Accelerating Perl Web Application 
Development" by Jonathan Rockway (2007) with Catalyst 5.80013.


And in chapter 3 the autor says to create an index.tt2 page and said 
that we don't need to do nothing cos Catalyst will recognize the 
index. I start the server and it shows me the default page of catalyst.


I'm following the book, so what i done wrong?
My guess would be that you haven't changed the template extension.  See 
if index.tt works.  From my recollection, the book is building on top of 
the previous example and only references some of the previously covered 
material rather than explicitly going through it again (so also make 
sure you have the view set up).


As a note, it's not that Catalyst "recognizes the index", it's that the 
view defaults to trying to display a template matching the present 
action (which in this case should be "index") with the template 
extension appended.




Thanks once again!

--
David Silva - http://davidslv.com/


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
  



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Feedback requested on HTML::FormHandler's new widget system

[Matt Whipple]

Hi, I'm a recent adopter of HFH, and was drawn to it partly in hopes of 
having a decently clean solution for form rendering (I've begun a system 
but don't think it will be usable anytime in the near future)  so I'll 
contribute my 2 cents.


From my perspective the output/rendering of the form data normally 
represents a static view of the data, a single state which will 
generally not require any return communication with the system which 
renders it.  I therefore see a more independent treatment of widgets the 
best option to allow those widgets to fit into the most places, and be 
made the most accessible for future growth.  Rather than treating the 
widgets as roles to be pulled into the form system, they could be 
external objects with a common interface which are pushed into and piped 
from. This aids in separation of concerns and could lead to afar more 
flexible, robust widget framework which is more conducive to 
collaboration and extension within and without the larger system. 


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Splitting up a large application: Shared config and templates for multiple applications

[Matt Whipple]

Bill Moseley wrote:
I'm exploring the idea of breaking up a large application into a 
number of separate Catalyst apps.  The application currently exists of 
a base application and a number of optional "products." For example, 
one product might be to add a calendar and scheduling to the application.


The base application has layout templates that all "products" need to 
use.  So each app would need to share a template path.  Also, each 
product would need access to application-wide configuration.


The reason I'm looking at this approach is so that different teams of 
developers can work on the products, test products separately, and 
release the products on different schedules.


Anyone building applications out of multiple small Catalyst 
applications like this?  How do you set up the apps to share templates 
and a config?  Anything more interesting than passing in paths?
One downside of this approach is we end up with a handful of very 
similar looking applications (same set of plugins, etc.), not to 
mention have to be careful about how session data is shared, and so 
on.  I wounder if it would be difficulst to customize the catalyst.pl 
script to include a standard set of plugins/roles that we use in every 
application -- e.g. have a skeleton app.


Subclass.  This could probably take care of sharing the template/config 
resources also, but otherwise I'd probably lean towards symlinking over 
modifying each app.





Oh, just noticed:

$ cat MyApp/myapp.conf
# rename this file to MyApp.yml and put a ':' in front of 'name' if
# you want to use YAML like in old versions of Catalyst
name MyApp

ConfigLoader looks for lower case file names, right?  That is, 
shouldn't that be "myapp.yml"?




--
Bill Moseley
mose...@hank.org 


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
  



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] What is correct way to re-check user password for authenticated user?

[Matt Whipple]

Oleg Kostyuk wrote:

Hello subscribers,

On some pages I need to re-check user password (to be more concrete -
each time when user change any settings on "user settings" page). I
can't compare passwords directly (something like: $form->{password} eq
$c->user->password()), because in DB I have only hashed passwords.
  

You could always just hash the supplied password and compare the hashes


Seems that I can try to authenticate user again, by calling
$c->authenticate(name=>$c->user->name, pass=>$form->{password}), but I
concerned is this acceptable - calling authenticate, when user is
already authenticated. And what will be if provided password is
incorrect - user will be auto-logout'ed or not?
  
I'd probably use the authentication again, but ensure that it treated 
logically as such and not lumped in with some CRUD (unless that's not 
how it's being used in which case you probably shouldn't use it).  I'm 
fairly sure a failed auth doesn't result in a logout, so you could use 
that as a means to redisplay the form with a message.



May be there is some other way, that is not obvious to me?

Any thoughts is welcome,
Thanks.

  



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] DBI SQLite driver missing after Catalyst update.

[Matt Whipple]

I've tried both formulations of the config string

__PACKAGE__->config(
   schema_class => 'wppig::Schema',
   connect_info => {
  dsn =>  'dbi:SQLite:wppig.db3',
   },
);
 
__PACKAGE__->config(

   schema_class => 'wppig::Schema',
   connect_info =>  'dbi:SQLite:wppig.db3',
);

and even from the docs that you cite

__PACKAGE__->config(
   schema_class => 'wppig::Schema',
   connect_info =>  {
  dsn =>  'dbi:SQLite:dbname=wppig.db3',
   },
 );

But I still get the same error message. No matter if I've got a 
hashref or a string set for connect_info I still see the "Can't 
connect to data source 'HASH(0x9e139e0)' " error.


Interestingly, when I remove the connect_info line I see this in the logs:
" Couldn't instantiate component "wppig::Model::wppigDB", Either 
->config->{connect_info} must be defined for wppig::Model::wppigDB or 
wppig::Schema must have connect info defined on it."


I'd suggest testing placing the connect_info in the app's config file 
(designated for the model), or in the schema file.  With the info in the 
schema file it isolates the connection within DBIC.




Since the the wppig/Schema.pm file has no config information in it, it 
must mean there's probably no other config file squirreled away 
affecting the connection.


As a side not you may want to meditate on the fact that you
apparently simultaneously introduced instability into a
development and a production environment (according to the other
reply thread)


Guilty as charged, I'll fix it as soon as I can get to it.
 



Debugging says the piece of code that it's hanging on looks
like this:

my $result = $c->model('DB::Result::Tag')->search(
   { },
   { join  => { 'items_tag' => 'tag' } }
);

while ( my $tag = $result->next ) { # Hangs here
   $tag_count{ $tag->tag }++;
}

So it looks like the class is loading but I can't do anything
with the ResultSet.

Any idea of why this is failing? Did I miss a step somewhere
in the conversion? I'd be happy to provide more information if
needed.

Thanks in advance for your help.



If there's something else about my app that I can show you to help 
solve this problem, please let me know. Thanks again for your help.



Collin Condray
@ccondray
condray.net 




___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
  



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] DBI SQLite driver missing after Catalyst update.

[Matt Whipple]

Collin Condray wrote:
I have recently updated my Catalyst installation from 5.71001 to 
version 5.80007 and have made one of my websites completely unusable. 
I followed the instructions in the tutorial 
(http://search.cpan.org/~hkclark/Catalyst-Manual-5.8000/lib/Catalyst/Manual/Tutorial/04_BasicCRUD.pod 
) 
to update the database to use load_components and have updated my 
schema files to match. However, when I go to my site I get the 
following error message:


DBIx::Class::ResultSet::next(): DBI Connection failed: Can't connect 
to data source 'HASH(0x9e139e0)' because I can't work out what driver 
to use (it doesn't seem to contain a 'dbi:driver:' prefix and the 
DBI_DRIVER env var is not set) at 
/home/me/local/share/perl/5.8.4/DBIx/Class/Storage/DBI.pm line 840
The error message there would seem to say that the dsn isn't being 
retrieved properly out of the config info


My connection string looks OK and matches the tutorial's example code:

__PACKAGE__->config(
schema_class => 'wppig::Schema',
connect_info => [
'dbi:SQLite:wppig.db3',
],
);

I'd opt for the more explicit and scalable key/value option of:

   connect_info => {
  dsn => 'dbi:SQLite:wppig.db3',
   },


But judging from the docs (which confusing do say arrayref)
http://search.cpan.org:80/~mstrout/Catalyst-Model-DBIC-Schema-0.26/lib/Catalyst/Model/DBIC/Schema.pm#connect_info

I'd say you'd be looking for
   connect_info => 'dbi:SQLite:wppig.db3',


As a side not you may want to meditate on the fact that you apparently 
simultaneously introduced instability into a development and a 
production environment (according to the other reply thread)




Debugging says the piece of code that it's hanging on looks like this:

my $result = $c->model('DB::Result::Tag')->search(
{ },
{ join  => { 'items_tag' => 'tag' } }
);

while ( my $tag = $result->next ) { # Hangs here
$tag_count{ $tag->tag }++;
}

So it looks like the class is loading but I can't do anything with the 
ResultSet.


Any idea of why this is failing? Did I miss a step somewhere in the 
conversion? I'd be happy to provide more information if needed.


Thanks in advance for your help.

Collin Condray
@ccondray
condray.net 


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
  



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Loading template according to request path

[Matt Whipple]

Eden Cardim wrote:

On Tue, Aug 11, 2009 at 2:15 PM, Matt Whipple wrote:
  

Thanks everyone for your input, I'm certainly gathering that there is
nothing preexisting that does what I'm looking to do.  I'll continue to
clean up my version and throw it on CPAN if it seems appealing enough.  As a
quick overview the basic premise is a more direct link from the path to the
template which would be used for those times when the URI path determines
presentation after passing through a reusable action handler which tailors
content (and doesn't necessarily have to worry about the template
selection).  This is presently done in the auto action so that overriding
the behavior is natural and any extended logic can be handled when and where
desired.



That's precisely what chained actions are for:

sub content : Chained('/') CaptureArgs(0) PathPart('content/as') {
my($self, $c) = @_;
$c->stash->{data} = $c->model('Content');
}

# /content/as/html -- renders root/content/as/html.tt
sub html : Chained('content') Args(0) {}

# /content/as/text -- renders root/content/as/text.tt
sub text : Chained('content') Args(0) {}

# /content/as/graph
# doesn't process a template at all as long as View::SVG sets $c->res->body
sub graph : Chained('content') Args(0) {
my($self, $c) = @_;
$c->forward('View::SVG'); # sets res->body, res->content_type, etc.
}

sub whatever : Chained('content') Args(0) { #etc... }

# insert jshirley's end action here

what's missing?
  
I considered using a chain, but figured sticking to my initial idea 
offers a more self-contained, flexible solution which potentially frees 
the controller actions to focus more on distinct processing and less on 
any indistinctly retrieved result destination.   Perhaps a more simple 
expression of what I'm looking to do is to override the TT View default 
of going to a template named according to the action to one named 
according to the path (with a little extra DWIMmery).  Consider, for 
example, an application for which you may want to use customized 
templates for certain edge cases in an application.  Rather than having 
to touch the code at all, the template could be dropped in place in the 
right path by a designer and automatically used by the application.  For 
now I'm going to try it and see if it's useful, counter-productive, or 
somewhere in the middle and then either release it for consumption or 
bury it and disavow any responsibility for its creation.


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Loading template according to request path

[Matt Whipple]

On Tue, Aug 11, 2009 at 3:01 PM, Matt Whipple <mailto:m...@mattwhipple.com>> wrote:


J. Shirley wrote:

On Tue, Aug 11, 2009 at 12:09 PM, Matt Whipple
mailto:m...@mattwhipple.com>
<mailto:m...@mattwhipple.com <mailto:m...@mattwhipple.com>>>
wrote:

   Is there a presently existing mechanism which flexibly
allows for
   template selection according to the request URI?  For
instance a
   request to www.myapp.com/somepage
<http://www.myapp.com/somepage> <http://www.myapp.com/somepage>

   would set something like stash(template => 'somepage.tt
<http://somepage.tt>
   <http://somepage.tt>') if the file exists and continue to be

   processed by the appropriate or default action.

   I wrote something which does this which I'm about to spend some
   time cleaning up and optimizing but don't want to be
reinventing
   any wheels (especially likely smoother ones).

   ___
   List: Catalyst@lists.scsys.co.uk
<mailto:Catalyst@lists.scsys.co.uk>
<mailto:Catalyst@lists.scsys.co.uk
<mailto:Catalyst@lists.scsys.co.uk>>

   Listinfo:
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
   Searchable archive:
   http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
   Dev site: http://dev.catalyst.perl.org/






Thanks everyone for your input, I'm certainly gathering that there is 
nothing preexisting that does what I'm looking to do.  I'll continue to 
clean up my version and throw it on CPAN if it seems appealing enough.  
As a quick overview the basic premise is a more direct link from the 
path to the template which would be used for those times when the URI 
path determines presentation after passing through a reusable action 
handler which tailors content (and doesn't necessarily have to worry 
about the template selection).  This is presently done in the auto 
action so that overriding the behavior is natural and any extended logic 
can be handled when and where desired. 


<http://blog.afoolishmanifesto.com>


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
  



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Loading template according to request path

[Matt Whipple]

J. Shirley wrote:
On Tue, Aug 11, 2009 at 12:09 PM, Matt Whipple <mailto:m...@mattwhipple.com>> wrote:


Is there a presently existing mechanism which flexibly allows for
template selection according to the request URI?  For instance a
request to www.myapp.com/somepage <http://www.myapp.com/somepage>
would set something like stash(template => 'somepage.tt
<http://somepage.tt>') if the file exists and continue to be
processed by the appropriate or default action.

I wrote something which does this which I'm about to spend some
time cleaning up and optimizing but don't want to be reinventing
any wheels (especially likely smoother ones).

___
List: Catalyst@lists.scsys.co.uk <mailto:Catalyst@lists.scsys.co.uk>
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/




This is the default behavior for View::TT, as it says in the POD:

If a stash item isn't defined, then it instead uses the 
stringification of the action dispatched to (as defined by $c->action) 
in the above example, this would be |message|, but because the default 
is to append '.tt', it would load |root/message.tt <http://message.tt>|.


Is that not what you wanted?

-J
  
That is matching according to action, I'm looking to match on path 
(without having to create logically redundant complementary actions).





___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
  



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Loading template according to request path

[Matt Whipple]

Is there a presently existing mechanism which flexibly allows for 
template selection according to the request URI?  For instance a request 
to www.myapp.com/somepage would set something like stash(template => 
'somepage.tt') if the file exists and continue to be processed by the 
appropriate or default action.


I wrote something which does this which I'm about to spend some time 
cleaning up and optimizing but don't want to be reinventing any wheels 
(especially likely smoother ones).


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/